Domain-Driven Design ou DDD, é uma abordagem que nos ajuda a ter sucesso na compreensão e construção de modelos de design de software. Ele nos fornece ferramentas de modelagem estratégicas e táticas para auxiliar no design de software de alta qualidade que atenda aos nossos objetivos de negócios.
Mais importante ainda, o Domain-Driven Design não tem a ver com tecnologia. DDD consiste em desenvolver conhecimento sobre o negócio e usar a tecnologia para agregar valor. Somente quando você for capaz de entender o negócio em que sua empresa atua, você poderá participar do processo de descoberta de modelos de software para produzir uma Linguagem Ubíqua.
Se você tiver mais de 30 casos de uso, seu sistema pode estar caminhando para a temida "grande bola de lama". Se você tem certeza de que seu sistema ficará mais complexo, deve começar a considerar o uso de DDD para combater a complexidade.
Aplicar o Design Orientado a Domínio completamente exigirá pensar no domínio do negócio, terminologia, pesquisa e colaboração com especialistas do domínio, em vez de jargões de codificação. Isso exigirá tempo e esforço.
Você precisa do comprometimento de especialistas em domínio para se envolver no processo de construção de software. Você precisará de especialistas em domínio para revelar um conhecimento profundo do domínio. Será necessária uma conversa aberta, saudável, respeitosa e contínua com os especialistas para modelar sua linguagem falada em software.
“Perguntar uma questão não deveria modificar sua resposta” - Bertrand Meyer
Este princípio de design afirma que cada método deve ser um Comando, que executa uma ação, ou uma Consulta, que retorna dados ao chamador, mas não ambos.
O CQRS é uma arquitetura poderosa e flexível. Há um benefício adicional em relação à coleta e ao salvamento de eventos de domínio (que ocorreram durante uma operação de agregação), proporcionando um alto nível de detalhes sobre o que está acontecendo em seu domínio. Eventos de Domínio são um dos principais padrões táticos devido à sua importância dentro do domínio, pois descrevem ocorrências passadas
A ideia fundamental por trás do Event Sourcing é expressar o estado dos Agregados como uma sequência linear de eventos
Objetos de Valor são um bloco de construção fundamental no Design Orientado a Domínio, usados para modelar conceitos da sua Linguagem Ubíqua no código
Podemos usar objetos como valores. O padrão para isso é Value Object*. Uma das restrições em usar Value Object
é que os valores das variáveis de instância do objeto nunca mudem uma vez que foram criados no construtor.
Este conceito possui uma identidade que perdura ao longo do tempo. Não importa quantas vezes os dados desses conceitos mudem, suas identidades permanecem as mesmas. É isso que os torna Entidades e não Objetos de Valor.
A intenção dos UUIDs é permitir que sistemas distribuídos identifiquem informações de forma única sem coordenação central significativa. Neste contexto, a palavra "único" deve ser usada para significar "praticamente único" em vez de "único garantido". Como os identificadores têm um tamanho finito, é possível que dois itens diferentes compartilhem o mesmo identificador. Esta é uma forma de colisão de hashes. O tamanho do identificador e o processo de geração precisam ser selecionados de forma a tornar isso suficientemente improvável na prática.
Entre os interatores do caso de uso e o banco de dados estão os gateways do banco de dados. Esses gateways são interfaces polimórficas que contêm métodos para cada operação de criação, leitura, atualização ou exclusão que pode ser realizada pelo aplicativo no banco de dados.
Um modelo de objeto do domínio que incorpora comportamento e dados.
Na pior das hipóteses, a lógica de negócios pode ser muito complexa. Regras e lógica descrevem muitos casos e inclinações de comportamento diferentes, e é com essa complexidade que os objetos foram projetados para trabalhar. Um Modelo de Domínio cria uma rede de objetos interconectados, onde cada objeto representa algum indivíduo significativo, seja ele do tamanho de uma corporação ou do tamanho de uma única linha em um formulário de pedido.
Agregação é um padrão em Design Orientado a Domínio. Uma agregação DDD é um conjunto de objetos de domínio que podem ser tratados como uma única unidade. Um exemplo pode ser um pedido e seus itens de linha; estes serão objetos separados, mas é útil tratar o pedido (junto com seus itens de linha) como um único agregado.
Um agregado terá um de seus objetos componentes como a raiz do agregado. Quaisquer referências externas ao agregado devem ir apenas para a raiz do agregado. A raiz pode, portanto, garantir a integridade do agregado como um todo.
As dependências do código-fonte devem apontar apenas para dentro, em direção a políticas de nível superior
src/
├── Entity/ -1
├── Mapping/ -2
├── Domain/ -3
├── Repository/ -4
├── ApplicationService/ -5
├── Session/ -6
├── Controller/ -7
A Camada entidade é implementada com o ORM Doctrine e implementa a classe pai “Entity” e interface "Subscriber".
A Classe Entity é a classe abstrata responsável por reaproveitar todas as operações que devem ser comuns á todas as entidades, contém facilidades como criar um novo Uuid , definir data de criação e atualização do objeto , um array publico “events” que deve armazenar todos os eventos que esta entidade participou .
Interface Subscriber implementa a abstração utilizada na raiz da agregação para inscrever um objeto como participante de um domínio.
É o mapeamento das entidades em XML para o ORM Doctrine, aqui são definidos o mapeamento relacional das entidades que devem acompanhar o banco de dados.
Contém todos os agregados e objetos que compõem o funcionamento do domínio para construir uma raiz da agregação e escutar eventos.
O domínio é inicializado em seu construtor e atribui a sí mesmo uma identidade que poderá ser utilizada para trabalhar com vários domínios ao mesmo tempo, todo evento delegado ao domínio deve seguir por uma SSOT(Unica fonte da verdade) estendido da classe pai, o método publico “apply” que recebe como parâmetro uma classe DomainEvent.
Os repositórios utilizados em cada domínio devem ser pré definidos na classe BookDomainRepository, que fornece acesso ao banco de dados através de projeções de models.
Para cada evento, o domínio irá reconstruir e validar sua integridade com todos os seus participantes.
Os participantes de uma AggregateRoot estendem a interface “Subscriber”, que utiliza o design pattern Strategy da classe DomainEventPublisher para acionar um método abstrato de seus participantes.
A camada de repositório é separada em repositórios de um domínio e repositórios individuais, sua consultas devem estar separadas entre consultas que podem ser executadas com repositórios individualmente e consultas que envolvem vários repositórios.
A camada de serviço se comunica com a camada de presentação através de uma SSOT(Unica fonte da verdade) desta forma todos os comandos recebidos devem atender a uma padronização de entrada e saída, esta camada também é responsável por separar comandos de perguntas e sincronizar as dependências de baixo nível para atender as solicitações da camada de presentação.
Atendendo o padrão de arquitetura CQRS (Command Query Responsability Segregation) esta camada pode se comunicar diretamente com a camada de repositório apenas para realizar consultas e delegar suas modificações para a camada de domínio.
A camada de controllers deve haver apenas duas responsabilidades, manusear as requisições HTTP e decidir que fazer com isto.