Modelando Dominios Ricos
-
Linguagem ubiqua: O cliente, time, domain experts, software... TODOS! Devem falar a mesma linguagem e os mermos jargões. O código deve refletir a linguagem utilizada. Traga tudo que for capturado nas conversas para o software. Caso utilize código em inglês, se não tiver tradudção apropriada, utilize o termo em português como o cliente falou.
-
Dominios Ricos vs Dominios Anemicos: Dominios ricos são mais fáceis de testar, reutilizar, entender e concentrar regras de dominio. Dominios Anemicos sao tendenciosos a ter apenas uma estrutura que reflete o repositorio de dados, dificulta a escrita de testes.
-
Sub-dominios: Possivel dividir um dominio em dominios menores.
-
Separação e Contextos Delimitados: A separação do dominio reflete um contexto. Uma mesma entidade pode estar presente em dois sub-dominios, mas com significados diferentes para o contexto em que apresenta. Ex: Cliente, em um contexto departamento financeiro o cliente é a pessoa que recebe dinheiro, já no contexto de vendas é a pessoa que paga!
-
Entidades: Representa artefatos do negócio que possuem uma identificação única no contexto.
-
Corrupção no Código: Sempre que possível proteja o dominio de ser corrompido. Não permita que as regras de negócio sejam puladas.
-
Primitive Obsession: Reduz o reuso, utilize VOs para melhorar a utilização de regras de valores de dominio.
-
Value Objects: Fazem parte da entidade, representam valores e não tem uma identificão única no contexto. Não são gerenciados sem sozinhos ou sem uma entidade.
-
CQRS: Command Query Responsability Segregation. Commands: Para escrita(input) Queries: Para leitura(output).
-
Repository: abstrai o acesso a dados do dominio.
-
Handlers: Tratatam as solicitações, fazem parse de commands para objetos de dominio e executar ações chamando serviços, repositorios, etc.