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

 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 Pizza que tem Azeitonas são as Pizzas de Mussarela?".

Comentários

Postar um comentário

Postagens mais visitadas deste blog

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

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

Imagem
  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.
Leia mais