Enfim, DDD - Padrões de projeto no front-end. Parte 2.

#ddd #programming #project

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?

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.