Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Wiki Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 52
    • Issues 52
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • CP - Planta
  • WikiWiki
  • Wiki
  • arquitetura

arquitetura · Changes

Page history
Create arquitetura wiki - with iniital repository architecture discussion authored Aug 22, 2024 by André Sacilotto Santos's avatar André Sacilotto Santos
Show whitespace changes
Inline Side-by-side
arquitetura.md 0 → 100644
View page @ 3371d19c
### Principios de arquitetura utilizado nos Repositórios e
### TDD (Test-Driven Development)
TDD é uma abordagem de desenvolvimento de software em que os testes são escritos antes do código funcional. O ciclo básico do TDD é "Red, Green, Refactor":
1. **Red**: Escreva um teste que falhe (não há funcionalidade implementada ainda).
2. **Green**: Escreva código suficiente para fazer o teste passar.
3. **Refactor**: Refatore o código para melhorar sua estrutura sem alterar sua funcionalidade.
O TDD ajuda a garantir que o código seja bem testado e que os desenvolvedores criem código funcional que atende exatamente aos requisitos especificados pelos testes.
### BDD (Behavior-Driven Development)
BDD é uma metodologia de desenvolvimento de software que estende o TDD (Test-Driven Development) para incluir uma abordagem centrada no comportamento do usuário. Em BDD, o foco está em definir o comportamento do sistema em termos de histórias de usuários e critérios de aceitação, escritos em uma linguagem natural que é compreensível para todas as partes interessadas, incluindo desenvolvedores, testadores e clientes.
**Exemplo de como funciona:**
- Um cenário típico em BDD é escrito na forma "Dado que... Quando... Então...".
- **Dado que**: define o estado inicial do sistema.
- **Quando**: descreve a ação que o usuário executa.
- **Então**: especifica o resultado esperado dessa ação.
BDD permite que as equipes capturem os requisitos funcionais de uma maneira clara e testável, focando no valor para o usuário final.
### DDD (Domain-Driven Design)
DDD é uma abordagem para o desenvolvimento de software que enfatiza a importância do modelo de domínio no centro de todos os processos de design. Em DDD, o software é estruturado em torno do domínio principal, usando uma linguagem ubíqua que reflete as preocupações do negócio.
**Componentes principais do DDD:**
- **Entidades**: Objetos que têm uma identidade única ao longo do tempo.
- **Agregados**: Um grupo de objetos que devem ser tratados como uma unidade.
- **Serviços de Domínio**: Lógicas que não pertencem a uma entidade específica.
- **Repositórios**: Objetos que fornecem acesso ao armazenamento de entidades e agregados.
- **Value Objects**: Objetos que são definidos apenas por seus atributos, sem identidade única.
### Uso de MVC em Aplicações Frontend
O MVC (Model-View-Controller) é uma arquitetura de software que separa as responsabilidades em três componentes:
- **Model**: Lida com a lógica de dados e a regra de negócios.
- **View**: Cuida da apresentação dos dados ao usuário.
- **Controller**: Intermediário que manipula as interações do usuário, chamando o modelo para processar os dados e atualizando a visualização.
**Justificativa no Frontend:**
No seu projeto de frontend, que envolve TypeScript, Next.js, e Tailwind CSS, a aplicação do MVC ajuda a organizar o código de forma que as responsabilidades estejam claramente definidas:
- **Model**: Representa os dados e a lógica que manipula esses dados, talvez via hooks ou state management.
- **View**: Implementa a interface do usuário, provavelmente usando componentes React estilizados com Tailwind CSS.
- **Controller**: Pode ser representado pelos handlers ou pela lógica de roteamento no Next.js, coordenando as interações do usuário e manipulando as requisições e respostas.
Essa separação facilita a manutenção, testes e evolução da aplicação, permitindo que diferentes partes do código possam ser desenvolvidas, testadas e refatoradas de maneira independente.
### Estrutura Modular no Backend
No backend, uma estrutura modular significa organizar o código em módulos independentes que encapsulam a lógica relacionada a um único aspecto do sistema (ex. autenticação, manipulação de dados, etc.).
**Justificativa no seu projeto:**
Em seu projeto, que utiliza um backend com Nest.js e o padrão de Clean Architecture, a estrutura modular é crucial para manter a separação de preocupações:
- **Modularidade**: Cada módulo no backend (como módulos de autenticação, banco de dados, API) é encapsulado, o que significa que suas dependências e lógicas são isoladas. Isso facilita o desenvolvimento paralelo e a refatoração.
- **Testabilidade**: A modularidade também permite testes mais granulares. Por exemplo, você pode testar um módulo de autenticação sem ter que se preocupar com a lógica do banco de dados.
- **Escalabilidade**: À medida que o sistema cresce, novos módulos podem ser adicionados sem impactar diretamente os existentes. Isso também ajuda a adotar práticas como DDD, onde cada módulo pode representar um agregado ou serviço de domínio.
Portanto, tanto o MVC no frontend quanto a estrutura modular no backend complementam o uso de TDD, BDD e DDD, fornecendo uma base sólida para o desenvolvimento de software escalável, testável e orientado ao domínio.
\ No newline at end of file
Clone repository
  • Infraestrutura
  • Utilizando a wiki
    • adicionando imagens
    • escrevendo em markdown
    • wiki no editor de texto
  • analytics
  • arquitetura
  • backend_categories
  • backend_inicio
  • backend_persons
  • backend_production_order
  • backend_products
  • backend_qualidade
  • backend_settings
  • backend_stock
  • backend_stock_locations
View All Pages