DDD — Domain-Driven Design
O que é?
O DDD é uma maneira de pensar e um conjunto de prioridades, voltado para a aceleração de projetos de software que têm que trabalhar com domínios complexos.
O DDD é uma abordagem de modelagem de software que segue um conjunto de práticas com objetivo de facilitar a implementação de complexas regras / processos de negócios que tratamos como domínio.
DDD é sobre design guiado pelo conhecimento do domínio.
O que DDD não é:
- Não é arquitetura em camadas;
- Não é tecnologia;
- Não é framework;
- Não é padrão;
- Não é linguagem;
Não faz sentido:
- Como implementar o padrão DDD?
- Qual framework DDD devo usar?
- Como fazer um CRUD usando DDD?
- Como criar um projeto DDD na plataforma .NET?
Quando não usar DDD:
- O DDD não vai te ajudar a gerenciar melhor os dados;
- Não vai te ajudar a aumentar o desempenho da sua aplicação;
- Não vai te ajudar na complexidade da tecnologia usada no projeto;
Quando considerar DDD
O DDD vai te ajudar a resolver problemas na complexidade do negócio.
A abordagem Domain-Driven Design será útil em projetos onde a complexidade da lógica de negócio justificar a sua adoção.
Alguns Benefícios
- Comunicação — Linguagem Ubíqua
- Código coeso
- Compreensão do negócio
- Enfatiza o domínio do negócio
Quando implementar
No livro de DDD do Vaughn Vernon, você vai encontrar:
Se seu Projeto… Se sua aplicação for completamente centrada em dados e se qualificar verdadeiramente para uma solução CRUD pura, em que cada operação é basicamente uma consulta simples de banco de dados para criar, ler, atualizar ou excluir, você não precisa do DDD. Sua equipe só precisa colocar um rosto
bonito em um editor de tabelas de banco de dados. Em outras palavras, se você puder confiar no fato de que os usuários irão inserir os dados diretamente em uma tabela, atualizá-los e, às vezes, excluí-los, você nem mesmo precisará de uma interface do usuário. Isso não é realista, mas é conceitualmente relevante. Se pudesse usar uma ferramenta simples de desenvolvimento de banco de dados para criar uma solução, você não desperdiçaria o tempo e dinheiro de sua empresa no DDD.
Pontos: 0.
Pensamentos de Suporte: Isso parece óbvio, mas normalmente não é fácil determinar
simples versus complexo. Não é como se todas as aplicações que não são CRUD puras merecem o tempo e o esforço
do uso do DDD. Assim, talvez possamos sugerir outros indicadores para nos ajudar a traçar uma linha entre o que é complexo e o que não é …
Se seu Projeto… Se seu sistema exigir apenas 30 ou menos operações de negócio, ele provavelmente é bem simples. Isso significaria
que a aplicação não teria um total de mais de 30 histórias de usuário ou fluxos de caso de uso, com cada um desses fluxos tendo apenas uma lógica mínima de negócio. Se você puder desenvolver rápida e facilmente esse tipo de aplicação e não se importar com a falta de poder e controle em relação à complexidade e alteração, o sistema provavelmente não precisará usar o DDD.
Pontos: 1
Pensamentos de Suporte: Isso parece óbvio, mas normalmente não é fácil determinar
simples versus complexo. Não é como se todas as aplicações que não são CRUD puras merecem o tempo e o esforço
do uso do DDD. Assim, talvez possamos sugerir outros indicadores para nos ajudar a traçar uma linha entre o que é complexo e o que não é …
Se seu Projeto… Assim, digamos que, em algum lugar no intervalo entre 30 e 40 histórias de usuário ou fluxos de caso de uso, a complexidade poderia ser pior. Seu sistema pode estar entrando no território do DDD.
Pontos: 2
Pensamentos de Suporte: O risco é do comprador: Bem frequentemente a complexidade não é reconhecida rapidamente. Nós, desenvolvedores de software, somos realmente muito bons para subestimar a complexidade e o nível de esforços. Só porque talvez queiramos codificar uma aplicação em N camadas com diversos Patterns não significa que devemos. No longo prazo, essas aplicações poderiam prejudicar mais do que ajudar.
Se seu Projeto… Mesmo que a aplicação não seja complexa agora, a complexidade dela aumentará? Você só pode saber isso ao certo depois que os usuários reais começam a trabalhar com ela, mas há um passo na coluna “Pensamentos de suporte” que pode ajudar a revelar a situação real.
Tenha cuidado aqui. Se houver absolutamente qualquer indício de que a aplicação tem complexidade mesmo moderada — este é um bom momento para ser paranoico — , isso pode ser uma indicação suficiente de que ela na verdade será mais do que moderadamente complexa. Incline-se em direção ao DDD.
Pontos: 3
Pensamentos de Suporte: Aqui vale a pena analisar os cenários de uso mais complexos com especialistas em domínio e ver aonde eles levam.Os especialistas em domínio:
#1 Já estão solicitando recursos mais complexos? Se sim, isso provavelmente é uma indicação de que a aplicação já é ou em breve se tornará excessivamente complexa para usar uma abordagem CRUD.#2 Estão entediados com os recursos ao ponto em que dificilmente vale a pena discuti-los? Provavelmente não é complexa.
Se seu Projeto… Os recursos da aplicação serão alterados com frequência ao longo de alguns anos, e você não pode antecipar que as alterações serão simples.
Pontos: 4
Pensamentos de Suporte: O DDD pode ajudá-lo a gerenciar a complexidade da refatoração de seu modelo ao longo do tempo.
Se seu Projeto… Você não entende o Domínio porque ele é novo. Na medida em que você e sua equipe sabem, ninguém fez isso antes. Isso provavelmente significa que ele é complexo ou, pelo menos, merece a devida diligência com análise analítica para determinar o nível de complexidade.
Pontos: 5
Pensamentos de Suporte:
Você precisará trabalhar com Domain Experts e testar os modelos para fazer a coisa certa. Você certamente também pontuou em um ou mais dos critérios anteriores, portanto, use o DDD.
Ao finalizar este exercício você terá mais clareza para determinar se o DDD é viável ou não para o seu projeto. Lembre-se de tomar as decisões com foco na simplicidade, entrega e manutenção. Muitas vezes sofremos da vontade incontrolável de implementar todos os conceitos de nossos estudos, porém estamos colocando em risco o dinheiro da empresa e nossa própria carreira.
Ubiquitous Language
O que é
- Vocabulário de termos específicos de domínio.
Substantivos, verbos, adjetivos, expressões idiomáticas e até advérbios. - Compartilhado por todas as partes envolvidas no projeto.
Objetivo principal de evitar mal-entendidos. - Usado em todas as formas de comunicação falada e escrita.
Linguagem universal do negócio dentro de um contexto.
Motivação
- As pessoas usam termos diferentes para as mesmas coisas;
- A Ubiquitous Language ajuda a ter uma terminologia comum;
- Ajuda a entender os requisitos do usuário de forma clara;
Por que surgem problemas na comunicação.
Definição
É a linguagem onipresente no modelo, na empresa, no contexto delimitado.
Essa linguagem deve ser usada em todos os lugares:
- Histórias de usuário
- Reuniões
- E-mails
- Documentação Técnica
- Planejamento, Cronograma
- Código Fonte
A Linguagem Ubíqua deve ser compartilhada e desenvolvida pela equipe, por desenvolvedores e especialistas no domínio.
Modelagem Estratégica
Antes…
Hoje…
Bounded Context
O que é?
- Espaço delimitado onde um elemento tem um significado bem definido.
Quaisquer elementos da linguagem onipresente. - Para além das fronteiras do contexto, a linguagem muda.
Cada contexto limitado tem sua própria linguagem onipresente. - Domínio de negócios dividido em uma teia de contextos interconectados.
Cada contexto tem sua própria arquitetura e implementação.
Contexto delimitado é um padrão central no design orientado a domínio. É o foco da seção de design estratégico do DDD, que trata de lidar com grandes modelos e equipes.
O DDD lida com modelos grandes, dividindo-os em diferentes contextos limitados e sendo explícito sobre seus inter-relacionamentos.
Um contexto delimitado é um limite explícito dentro do qual um modelo de domínio existe. Dentro do limite, todos os termos e frases da linguagem ubíqua têm um significado específico.
Um contexto limitado é o limite em um domínio em que um modelo de domínio específico se aplica.
Os contextos delimitados buscam delimitar o seu domínio complexo em contextos baseados nas intenções do negócio.
Isto significa que você deve delimitar as intenções de suas entidades com base no contexto que ela pertence.
Motivação
- Remover ambiguidade e duplicação;
- Simplifique o design de módulos de software;
- Integração de componentes externos;
Relações entre sub-dominios
- Parceria
- Kernel Compartilhado
- Desenvolvimento Cliente Fornecedor (upstream/downstream)
- Conformista
- Camada Anticorrupção
- Linguagem Publicada
Grande Bola de Lama
Relação entre Bounded Context e Microservice
Modelagem Tática
Os tijolos da construção de um design baseado em modelos.
Aggregate Object
Uma entidade que é a raiz agregadora de um processo do domínio que envolve mais de uma entidade.
- Algumas entidades individuais constantemente usadas e referenciadas juntas;
- Cluster de objetos associados tratados como um para alterações de dados;
- Possui uma entidade raiz;
- Preservar a integridade transacional;
- Evita a grande bola de lama;
- A raiz de agregação é ponto de entrada para o agregado;
- Uma entidade mesmo não sendo a raiz, pode acessar uma raiz de agregação;
Relação entre agregados.
Os objetos só podem ser acessados através de sua raiz de agregação.
Entity
Uma entidade do domínio, possui estados e comportamentos, lógica de negócio, getters e setters AdHoc, etc. Não tem lógica de persistência.
Você pode utilizar o Specification Pattern para validar a entidade.
Value Object
Um objeto que agrega valor às entidades, não possui identidade e é imutável.
Veja mais em: https://www.pluralsight.com/blog/software-development/domain-driven-design-csharp
Domain Service
Serviço do domínio que atende partes do negócio que não se encaixam em entidades específicas, trabalha com diversas entidades, realiza persistência através de repositórios e etc.
Repository
Uma classe que realiza a persistência das entidades se comunicando diretamente com o meio de acesso aos dados, é utilizado apenas um repositório por agregação.
Specification Pattern é uma opção para construir o repositório.
Generic Repository para agilizar a construção dos repositórios, fazendo a especialização em cada repositório especifico.
UoW (Unit of Work) para trabalhar com transação.
Application Service
Serviço de aplicação que orquestra ações disparadas pela camada de apresentação e fornece DTOs/ViewModel para comunicação entre as demais camadas e para o consumo da camada de apresentação.
Orquestra a ordem como o domínio será consumido.
Define as funções que o software deve executar e direciona os objetos expressivos do domínio para resolver os problemas. Não contém as regras ou conhecimento do negócio, mas coordena as tarefas.
No CQRS é onde colocamos os Commands, Queries, Events e EventHandling.
Factory
Classe responsável por construir adequadamente um objeto / entidade.
Events
Um evento é algo que ocorreu no passado. Um evento de domínio é algo que ocorreu no domínio que você deseja que outras partes do mesmo domínio (em processo) tenham conhecimento. As partes notificadas geralmente reagem de alguma forma aos eventos.
Arquitetura Sugerida
Transaction Script Pattern
Um Roteiro de Transação organiza toda esta lógica primariamente como um único procedimento, fazendo chamadas diretas ao banco de dados ou usando um fino envoltório para acesso ao banco de dados.
Fowler, Martin. Padrões de Arquitetura de Aplicações Corporativas (p. 120).
Table Module Pattern
Uma única instância que trata a lógica de negócio para todas as linhas de uma tabela ou visão de um banco de dados.
Fowler, Martin. Padrões de Arquitetura de Aplicações Corporativas (p. 134).
Domain Model Pattern
Colocar um Modelo de Domínio em uma aplicação envolve a inserção de uma camada inteira de objetos que modelam a área de negócios com a qual você está trabalhando.
Você encontrará objetos que representam os dados do negócio e objetos que capturam as regras usadas pelo negócio.
Em sua maior parte, dados e processos são combinados para juntar os processos aos dados com os quais eles trabalham.
Fowler, Martin. Padrões de Arquitetura de Aplicações Corporativas (p. 126).
Presentation
Application
Envia dados prontos para a camada de apresentação prontos para uso (viewmodel ou dto).
Orquestra a ordem como o domínio será consumido.
Define as funções que o software deve executar e direciona os objetos expressivos do domínio para resolver os problemas. Não contém as regras ou conhecimento do negócio, mas coordena as tarefas.
Domain
Responsável por representar o conceito do negócio, informações sobre a situação e regras de negócio. Essa camada é o coração do software do negócio.
Infrastructure
Arquitetura Limpa
Arquitetura Cebola
Arquitetura Hexagonal — “Ports & Adapter”
Lembre-se: Existem diversas formas de construir o núcleo da aplicação.
O domínio deve ser o centro da aplicação, conforme ideias do Clean Architecture e Onion Architecture.
Espero que tenham gostado. Até a próxima.
Referências
- Pluralsight (Curso e imagens de Dino Esposito)
- Domain-Driven Design: Atacando as complexidades no coração (Eric Evans)
- Implementando Domain-Driven Design (Vaughn Vernon)
