Pular para o conteúdo principal

Camadas da Arquitetura do Projeto

Na engenharia de software, especialmente em arquiteturas como a Clean Architecture ou Layered Architecture, o repositório atua como uma ponte entre o domínio e o banco de dados. Acima dele, as camadas se tornam mais focadas em regras de negócio e interface. [1, 2, 3, 4]
Aqui está a organização hierárquica, do mais próximo ao repositório até o topo (usuário):

1. Camada de Domínio / Negócio (Service Layer / Use Cases) [5]

É o "cérebro" da aplicação. Ela contém as regras que definem como o negócio funciona, independentemente de ser um site ou um aplicativo mobile. [6, 7, 8]
  • O que faz: Coordena a lógica de negócio. Ela chama o repositório para buscar dados, aplica validações, cálculos e regras de estado, e decide o que deve ser salvo.
  • Tipos de Dados:
    • Entities (Entidades): Objetos de negócio com identidade (ex: um Usuario com ID).
    • Value Objects: Objetos que definem atributos sem identidade própria (ex: Cpf, Email, Endereco). [9, 10, 11, 12, 13]

2. Camada de Aplicação / Adaptação (Application Layer / Controllers)

Esta camada serve como um tradutor. Ela recebe os comandos do mundo externo e os converte em algo que a camada de domínio entenda. [14]
  • O que faz: Recebe requisições HTTP, valida o formato dos dados de entrada e orquestra a chamada dos serviços de domínio.
  • Tipos de Dados:
    • DTOs (Data Transfer Objects): Objetos simples, sem lógica, usados apenas para carregar dados do ponto A ao ponto B.
    • Input Models / Request: Formatos específicos de entrada de dados. [15]

3. Camada de Apresentação / Interface (UI Layer) [16]

É a camada com a qual o usuário ou outros sistemas interagem diretamente. [17, 18]
  • O que faz: Exibe as informações ao usuário e captura suas interações. Pode ser uma API REST, uma interface gráfica (React, Flutter) ou até uma linha de comando (CLI).
  • Tipos de Dados:
    • ViewModels / Response Models: Versões "limpas" dos dados, formatadas especificamente para exibição (ex: formatar uma data de 2023-10-27 para 27/10/2023 ou ocultar a senha do usuário).
    • JSON / XML / HTML: Os formatos de serialização para transporte final. [19, 20, 21, 22]
Resumo da Hierarquia de Fluxo:
  1. UI: Recebe JSON, transforma em Request DTO.
  2. Controller: Valida o DTO e chama o Service.
  3. Service: Converte o DTO em Entidade, processa a lógica e chama o Repository.
  4. Repository: Persiste a Entidade no banco (ou a mapeia para um Schema/DAO). [23, 24]

Em um projeto Blazor Server seguindo a Clean Architecture, a organização segue a regra de ouro: as dependências sempre apontam para dentro (em direção ao Domínio).

Aqui está onde cada item deve ser localizado e o porquê:

1. Value Objects [1]

Onde ficam: No projeto Domain (ou Core.Domain).
  • Pasta sugerida: Domain/ValueObjects/ ou junto das entidades relacionadas.
  • Motivo: Eles representam conceitos fundamentais do negócio (ex: Cpf, Endereco, Preco) que não possuem identidade própria e são imutáveis. O domínio deve ser o lugar mais "puro" da aplicação, sem dependências externas. [2, 3, 4, 5]

2. Interfaces de Repositório (Contratos)

Onde ficam: No projeto Domain (ou as vezes no Application). [6]
  • Pasta sugerida: Domain/Repositories/ ou Domain/Interfaces/.
  • Motivo: Na Clean Architecture "pura", o domínio define as necessidades de persistência (o "quê" o sistema faz). Isso permite que os Casos de Uso (na camada de Application) usem essas interfaces sem saber se os dados vêm de um SQL Server, MongoDB ou uma API externa. [7, 8, 9, 10, 11]

3. Repositórios (Implementação)

Onde ficam: No projeto Infrastructure (ou Infrastructure.Persistence).
  • Pasta sugerida: Infrastructure/Persistence/Repositories/.
  • Motivo: É aqui que você lida com detalhes técnicos como Entity Framework Core, ADO.NET ou Dapper. Esta camada conhece o banco de dados e implementa os contratos definidos no domínio. [4, 12, 13]

Resumo Visual da Estrutura

Camada (Projeto) [14, 15] ConteúdoDepende de...
DomainEntidades, Value Objects, Interfaces de RepositórioNinguém (é o núcleo)
ApplicationCasos de Uso (Services), DTOs, HandlersDomain
InfrastructureImplementação de Repositórios, DbContextApplication e Domain
WebUI (Blazor)Componentes .razor, ViewModels, Registro de DIApplication e Infrastructure

Dica para Blazor Server

No Blazor Server, o projeto de interface (WebUI) geralmente é o ponto de entrada que registra as dependências. Você injetará as interfaces de repositório (definidas no Domain) e o contêiner de DI do ASP.NET resolverá para as classes concretas (definidas na Infrastructure). [9, 10, 16]
Marcadores:

Comentários

Postar um comentário

Postagens mais visitadas deste blog

UML e comunicação entre Componentes

(conteúdo gerado com I.A.) Antes de abordarmos o conceito de Componentes, vale a pena analisar como um programador iniciante costuma estruturar uma aplicação. Geralmente, a escolha é construir um monólito tradicional, agrupando todas as classes de domínio (como Categoria, Produto, Compra, Venda, Pagamento, etc.) em uma única pasta de Entidades. Da mesma forma, criam-se pacotes globais para Repositórios, Serviços e Controllers. O grande problema dessa abordagem é que ela gera um forte acoplamento entre as classes e as camadas do sistema. À medida que a aplicação cresce, isso desencadeia uma série de dificuldades: Manutenção e modelagem complexas: As responsabilidades se misturam. Rapidamente, o código passa a ter diversos trechos onde as classes assumem funções que não deveriam ter, tornando a evolução do sistema confusa. Escalabilidade ineficiente: Para escalar o backend, é necessário replicar a aplicação inteira e todo o banco de dados. Além de consumir mais recursos, isso traz o ri...
Postar um comentário
Leia mais

Quando escolher Flask ou Quart no Python

Atualmente , considerando o suporte assíncrono já presente no Flask, a escolha entre Flask e Quart para uma API Server depende de vários fatores técnicos. Vejamos alguns critérios: Fonte:  https://pt.stackoverflow.com/questions/51268/qual-a-diferen%C3%A7a-entre-comunica%C3%A7%C3%A3o-ass%C3%ADncrona-e-s%C3%ADncrona Suporte Assíncrono : Flask : O Flask oferece suporte assíncrono por meio de extensões de terceiros, como  flask[async] . No entanto, seu desempenho assíncrono é inferior aos frameworks nativamente assíncronos. Quart : O Quart é uma reimplantação do Flask baseada no padrão ASGI (Asynchronous Server Gateway Interface). Ele utiliza E/S assíncrona em todo o código e é mais adequado para bases de código predominantemente assíncronas. Desempenho : Flask : Como aplicação WSGI, o Flask usa um único worker para cada ciclo de solicitação/resposta. Quando uma solicitação chega a uma visualização assíncrona, o Flask inicia um loop de eventos em uma thread, executa a função da vi...
Postar um comentário
Leia mais

Metodo para criar relacionamento entre tabelas sem dar erro cíclico EFCore

Quando estamos modelando o banco de dados no Entity Framework Core (ou em qualquer outra ferramenta) é muito comum criarmos o erro cíclico. Este erro ocorre devido ao banco de dados não conseguir determinar onde o relacionamento termina, causando um erro de loop. Vejamos uma situação real onde foi gerado esse problema: Um Professor leciona em várias Turmas, Um Professor leciona uma ou mais Disciplinas, Um Professor leciona determinadas Disciplinas em determinadas Turmas, Uma Turma tem muitos Professores, Em todas as Turmas tem 9 Disciplinas. Em todas as turmas podem ter até 9 Professores. Só por essa descrição já é possível perceber que os relacionamentos podem ser complexos de entender. E tem-se também o problema da navegação em via dupla: Professor-Turmas, Turma-Professores. Então, como modelar essas tabelas sem que o banco entre em loop? Para resolver esse problema no Entity Framework Core e evitar o erro de "Multiple Cascade Paths" (caminhos múltiplos de cascata) comum n...
Postar um comentário
Leia mais