O que é o DDD?
“É um conjunto de princípios com foco em domínio, exploração de modelos de formas criativas e definir e falar a linguagem Ubíqua, baseado no contexto delimitado."
Como falado no post anterior (Padrões de projeto no front-end? - Parte 1), projetos modulares conseguem oferecer um bom meio termo quando monolitos tornam-se caóticos e microsserviços confusos e necessitam de mais pessoas.
Mas depois de entender que modularizar é um bom caminho para o projeto, entra o próximo desafio: definir os módulos.
E essa parte é confusa, pois muitos módulos convergem uns nos outros.
É nesse ponto que o DDD ajuda.
O DDD possibilita a melhor modelagem do software, com foco nas regras da aplicação (princípos, regras e processos) que são complexas e precisam de atenção. Isso permite que o software evolua gradualmente e que diferentes áreas possam conversar entre si sem impactar a outra.
Quando usar?
Utiliza-lo só faz sentido em softwares complexos e apenas.
Uma vez que a proposta é exatamente lidar com a complexidade com mais eficiência.
O que faz um software ser complexo?
A transcrição dessas regras e interpretações em código é o que torna o software complexo.
O DDD
Domínios
O DDD interpreta o projeto dividindo em duas classes:
O Domínio: é o core do negócio.
Exemplo: Um site para transmissões ao vivo.
O Subdomínio: são as partes menores que compõe o domínio central.
Exemplo: chats, players, canais e etc.
Linguagem universal
Ele também ajuda a criar uma linguagem universal, padronizando a nomenclatura e facilitando a interpretação e conversação das àreas.
Bounded Contexts ou Contexto delimitados
O Bounded Contexts consiste em separar a sua aplicação, onde cada sessão será um conjunto de termos, regras e definições consistentes.
Enquanto escrevia esse artigo, eu vi um exemplo no reddit muito bom.
The 'bounded context' is a doll house, inside of it is where you keep things that 'belong' inside - a dining table, a kitchen, and a bathtub. You wouldn't put a tree or a road sign inside, because they don't belong inside.
Um outro exemplo muito bom da mesma thread é de um e-commerce:
Mesmo objeto. Valores e relevâncias diferentes.
Assim, o pedido deve ter as informações necessárias em ambos os setores, mas cada uma é independente.
O setor de pedidos pode adicionar outras formas de pagamentos ou o setor do armazém pode adicionar novas formas de entrega, as alterações não irão sobreescrever o que é relevante pra outra àrea.
Veja a thread
Isso auxília na criação do design da aplicação, tornando-o mais estratégico.
Design do sistema
Com essa visão macro do sistema, é mais fácil mapear as entidades, os procedimentos e eventos de domínio envolvidas na aplicação.
Complexidade de negócio vs Complexidade Técnica
Outra ponto que também é facilitado é separar a complexidade em dois contextos: o que é complexo devido as regras de negócio e o que é complexo por questões técnicas.
Problemas
A visão macro construida até então do domínio, será o ponto de partida para enxergar os problemas que o sistema possui e assim criar subdomínios
Para cada um dos subdomínios deve ser criado um Bounded Context(ver sessão anterior) para a solução final.
Contexto é a chave primária pra nomenclatura
Existe a possibilidade de uma mesma palavra ter significados diferentes, da mesma maneira, pode ocorrer de palavras diferentes, terem significados iguais. Logo, o ideial é delimitar o domínio para que essas entidade(s) possam co-existir.
Diferentes entidades, mesmo nome
Imagine uma empresa b2b e b2c, customer para o b2b é uma empresa, com informações e funções diferentes, enquanto que para o b2c é algo totalmente diferente. Ambos são salvos na entidade 'customer'. Para total compreensão e controle das features, o ideal seria delimitar essas entidades em contextos diferentes.
Mesma entidade, funcionalidades diferentes
Voltando ao exemplo do pedido, o pedido é um só para o site e para o armazé, porém, necessitam de features diferentes.
No site, a entidade pedido precisa lidar com compra/venda
No armazém, retirada, transporte e entrega.
Padrões de mapeamento de contexto
Mapeamento de contextos
Considerando o exemplo inicial, um site para transmissões ao vivo.
Back-end
Front-end
More...
“É um conjunto de princípios com foco em domínio, exploração de modelos de formas criativas e definir e falar a linguagem Ubíqua, baseado no contexto delimitado."
Como falado no post anterior (Padrões de projeto no front-end? - Parte 1), projetos modulares conseguem oferecer um bom meio termo quando monolitos tornam-se caóticos e microsserviços confusos e necessitam de mais pessoas.
Mas depois de entender que modularizar é um bom caminho para o projeto, entra o próximo desafio: definir os módulos.
E essa parte é confusa, pois muitos módulos convergem uns nos outros.
É nesse ponto que o DDD ajuda.
O DDD possibilita a melhor modelagem do software, com foco nas regras da aplicação (princípos, regras e processos) que são complexas e precisam de atenção. Isso permite que o software evolua gradualmente e que diferentes áreas possam conversar entre si sem impactar a outra.
Quando usar?
Utiliza-lo só faz sentido em softwares complexos e apenas.
Uma vez que a proposta é exatamente lidar com a complexidade com mais eficiência.
O que faz um software ser complexo?
- As regras de negócio.
- As àreas envolvidas e/ou relacionadas.
- A interpretação que cada pessoa tem.
A transcrição dessas regras e interpretações em código é o que torna o software complexo.
O DDD
Domínios
O DDD interpreta o projeto dividindo em duas classes:
- Domínio
- Subdomínio
O Domínio: é o core do negócio.
Exemplo: Um site para transmissões ao vivo.
O Subdomínio: são as partes menores que compõe o domínio central.
Exemplo: chats, players, canais e etc.
Linguagem universal
Ele também ajuda a criar uma linguagem universal, padronizando a nomenclatura e facilitando a interpretação e conversação das àreas.
Bounded Contexts ou Contexto delimitados
O Bounded Contexts consiste em separar a sua aplicação, onde cada sessão será um conjunto de termos, regras e definições consistentes.
Enquanto escrevia esse artigo, eu vi um exemplo no reddit muito bom.
The 'bounded context' is a doll house, inside of it is where you keep things that 'belong' inside - a dining table, a kitchen, and a bathtub. You wouldn't put a tree or a road sign inside, because they don't belong inside.
Um outro exemplo muito bom da mesma thread é de um e-commerce:
- No site: O PEDIDO tem informações importantes como preço, impostos e etc.
- No armazém: O PEDIDO tem outra 'cara', nele o que mais importa são os códigos e endereços.
Mesmo objeto. Valores e relevâncias diferentes.
Assim, o pedido deve ter as informações necessárias em ambos os setores, mas cada uma é independente.
O setor de pedidos pode adicionar outras formas de pagamentos ou o setor do armazém pode adicionar novas formas de entrega, as alterações não irão sobreescrever o que é relevante pra outra àrea.
Veja a thread
Isso auxília na criação do design da aplicação, tornando-o mais estratégico.
Design do sistema
Com essa visão macro do sistema, é mais fácil mapear as entidades, os procedimentos e eventos de domínio envolvidas na aplicação.
Complexidade de negócio vs Complexidade Técnica
Outra ponto que também é facilitado é separar a complexidade em dois contextos: o que é complexo devido as regras de negócio e o que é complexo por questões técnicas.
Problemas
A visão macro construida até então do domínio, será o ponto de partida para enxergar os problemas que o sistema possui e assim criar subdomínios
Para cada um dos subdomínios deve ser criado um Bounded Context(ver sessão anterior) para a solução final.
Contexto é a chave primária pra nomenclatura
Existe a possibilidade de uma mesma palavra ter significados diferentes, da mesma maneira, pode ocorrer de palavras diferentes, terem significados iguais. Logo, o ideial é delimitar o domínio para que essas entidade(s) possam co-existir.
Diferentes entidades, mesmo nome
Imagine uma empresa b2b e b2c, customer para o b2b é uma empresa, com informações e funções diferentes, enquanto que para o b2c é algo totalmente diferente. Ambos são salvos na entidade 'customer'. Para total compreensão e controle das features, o ideal seria delimitar essas entidades em contextos diferentes.
Mesma entidade, funcionalidades diferentes
Voltando ao exemplo do pedido, o pedido é um só para o site e para o armazé, porém, necessitam de features diferentes.
No site, a entidade pedido precisa lidar com compra/venda
No armazém, retirada, transporte e entrega.
Padrões de mapeamento de contexto
- Partnership
- Shared Kernel
- Customer-Supplier Development
- Conformist
- Anticorruption-layer
- Open host service
- Published language
- Separate ways
- Big Ball of Mud
Mapeamento de contextos
Considerando o exemplo inicial, um site para transmissões ao vivo.
Back-end
Front-end
More...