Easiness

Esse documento auxiliará no desenvolvimento do Backend da Aplicação

Dados do projeto

Empresa:
Nome do app: Easiness
Site:
Site Temp:
Endpoint:
Tecnologias de desenvolvimento: Node js | (Input - Typescript) -> (Output -- Javascript)

Requisitos

VS Code - Recomendado
Node LTS - Obrigatório
Cmder - Recomendado
Postman - Recomendado
Document This - Opcional

Dependencias

Instalação Requisitos

Via Executavel.

Instalação Dependencias

Via NPM ou YARN.

Estrutura dos arquivos do Backend

/ - Arquivos de códigos da aplicação.
presentation/app.ts - Arquivo inicial.
presentation/config.json - Arquivo com configurações do projeto como configurações de banco de dados.
presentation/controllers/ - pasta com os controllers da aplicação.
application/autoMappers/ - pasta com os automappers da aplicação.
application/commons/ - pasta com os arquivos comuns a toda aplicação.
application/interfaces/ - pasta com as interfaces dos services da aplicação.
application/models/ - pasta com os models da aplicação.
application/services/ - pasta com os services da aplicação.
domain/entities/ - pasta com as entities da aplicação.
domain/interfaces/ - pasta com as interfaces dos repositories da aplicação.
infrastructure/crosscutting/ioc/ - pasta com as configurações da inversão de controle da aplicação.
infrastructure/crosscutting/ioc/inversify.config.ts - Arquivo responsável pela injeção de dependencias.
infrastructure/data/ - pasta com as configurações do banco, persistência de dados e etc.
infrastructure/data/context/ - pasta com as configurações do banco de dados da aplicação.
infrastructure/data/extensions/ - pasta com as extensões da aplicação.
infrastructure/data/repositories/ - pasta com os repositories da aplicação.
gitignore - Configura arquivos a serem ignorados pelo git.
package.json - Arquivo de dependências e detalhes da aplicacação.
tsconfig.json - Arquivo com configurações do transpile da aplicação.
README.md - Leia-me com instruções.

Nomeação dos arquivos e componentes

Os arquivos que contém código ts devem ser nomeados com a extensão .ts.

GitFlow

O GitFlow Workflow é um design de fluxo de trabalho Git que define um modelo de ramificação projetado em torno da versão do projeto. Isso fornece uma estrutura robusta para gerenciar projetos maiores.
Saiba mais sobre o GitFlow.
Explicação da ferramenta git-flow se for usar ela.

Versionamento Semântico

O Versionamento Semântico são regras que formalizam de forma prática e eficiente o incremento de versões de software. O versionamento do Simple Parking deve basedado na versão 2 do Versionament Semântico utilizando as regras 2, 3, 4, 6, 7, 8, 9 e 11 encontradas no site do samver.org.

Commits Semânticos

Para uma melhor navegação pelos commits, possibilitando um entendimento melhor e mais rápido, e consequentemente melhorando a manutenção do sistema, utilizamos um padrão na escrita do commit similar ao proposto por http://karma-runner.github.io/3.0/dev/git-commit-msg.html. As linhas das mensagens de commit não devem exceder 72 caracteres. Essa convenção permite uma boa leitura dos commits na maiorias dos terminais.

Formato da mensagem de commit:
<tipo>(): <assunto>
<linha em branco>
<mensagem>
<linha em branco>
<rodapé>

Exemplo:

chore(tslint): instalar dependência tslint

A dependência tslint é um utilitário de linting para TypeScript.
Auxilia o desenvolvedor a escrever o código em um padrão
preestabelecido.

BREAKING CHANGE:
Quanto ao foo.bar, foo.baz deve ser utilizado ao invés disso.

<tipo>:

feat - nova funcionalidade/recurso (features)
fix - correção de bug
perf - uma mudança de código que melhora a performance
docs - alterações na documentação
style - formatação, falta de ponto e vírgula, etc; não afetam o significado do código
refactor - refatoração do código, não corrige um bug nem adiciona um recurso; por exemplo, renomear variável
test - adição ou correção de testes
chore - atualizando tasks do Grunt, Webpack, etc; mudanças que não modificam o src/

<escopo>: Opcional, principalmente se a alteração for global.
Exemplos: init, runner, watcher, config, web-server, proxy, etc.

<assunto>: Deve ser escrito na forma imperativa, ou se preferir, de uma forma que complete a frase "Se aplicado, este commit irá ".

<corpo>: Deve conter descrições mais precisas do que está contido no commit, mostrando as razões ou consequências geradas pela alteração, assim como instruções futuras.

<rodapé>: È dedicado para notas e avisos importantes, como fechamento de issue e se existem mudanças radicais que quebrem funcionalidades. No caso de mudanças de quebras (BREAKING CHANGE) deve ser indicado “BREAKING CHANGE:” seguido com a explicação que leva a inclusão dessa marcação.

MarlonLira/Easiness