Repositórios não devem ser disponibilizado para os clientes

 Supondo que você trabalha em um sistema de uma pizzaria e há uma funcionalidade para preparar uma Pizza de Calabresa. Para essa funcionalidade você irá utilizar 3 repositórios, um para pegar uma Massa de pizza, outro para pegar as Calabresas e mais um para pegar o Queijo.


Solução

Ter uma camada de Domínio onde vamos ter a implementação das Entidades, Casos de Uso e etc. Tudo relacionado às regras de negócio da aplicação.

Ter uma camada que podemos chamar de Componente. Que irá utilizar os Casos de Uso e adaptadores (Repositórios, etc) disponibilizados pela camada de Domínio, então esse Componente proverá uma API pública para o Cliente, que vai conter os Casos de Uso necessários que serão executados na camada da aplicação.



Comentários

Postar um comentário

Postagens mais visitadas deste blog

Um caso de uso não deve depender de outro caso de uso

Imagem
  Supondo que tenho um caso de uso que prepara uma Pizza de Mussarela e outro que prepara uma Pizza de Calabresa. O dono da pizzaria me pediu para preparar uma Pizza de Calabresa com Queijo, então pensei, "Basta eu alterar o Caso de Uso da Pizza de Calabresa inserindo o Caso de Uso da Pizza de Mussarela antes de colocar as Calabresas". A implementação acima pode até ser uma boa ideia caso a Pizza de Mussarela nunca mude, porém, supondo que o dono da pizzaria decida que: "As Pizzas de Mussarela devem ter Azeitonas". Então, outro funcionário foi lá e alterou o Caso de Uso que prepara uma Pizza de Mussarela para conter Azeitonas. Certamente vamos ter uma Pizza de Calabresa sendo preparada de um forma um pouco diferente pois o preparo da Pizza de Calabresa está dependendo do preparo da Pizza de Mussarela. Certamente o dono da pizzaria vai lhe fazer a seguinte pergunta: "Por que começamos a produzir Pizzas de Calabresa com Azeitonas se em nosso cardápio a única Pizz...
Leia mais

O que são Aggregates?

No Domain-Driven Design (DDD), Aggregates desempenham um papel crucial na definição e agrupamento de entidades e value objects sob uma única raiz de agregação, garantindo consistência e integridade dos dados em operações complexas. Um Aggregate é um conjunto de entidades e value objects tratados como uma única unidade de consistência, com uma raiz de agregação (Aggregate Root) que é a única entidade exposta ao mundo externo para manipulação e acesso. O Aggregate Root garante a integridade dos dados, aplicando regras de negócio e encapsulando toda a lógica necessária. Características dos Aggregates Integridade Consistente : Aggregates garantem que todas as alterações dentro de um conjunto de entidades sejam feitas de forma consistente. Isolamento : Operações fora do Aggregate não podem modificar diretamente seus componentes internos. Toda a interação deve passar pela raiz do agregamento. Regra de Negócio Centralizada : A lógica de negócio é centralizada no Aggregate Root, assegurando qu...
Leia mais