A alguns anos atrás a divisão entre tecnologia e negócios era algo presente na maior parte das organizações, havia uma barreira entre áreas criando a necessidade de “passagem de bastão” a cada projeto de tecnologia. Mas isso tem mudado cada vez mais rápido. Podemos ver a evolução desse modelo buscando aproximar cada vez mais essas duas áreas, essa barreira deixa de existir e cada vez mais diminuiremos a passagem de bastão, até que um dia teremos apenas uma equipe, onde tecnologia será parte do negócio.
Essa evolução traz uma necessidade, nós de tecnologia precisamos entender cada vez mais o negócio, hoje vamos falar um pouco sobre algo que pode nos ajudar nessa jornada.
DDD – Qual problema resolve?
Com a aproximação das equipes algumas evoluções se tornaram necessárias, e alguns problemas começaram a ficar mais evidentes. Antes com projetos gigantes e equipes separadas, tínhamos documentações específicas e detalhadas para cada um dos projetos. Horas e horas eram gastas com uma das linguagens mais difíceis de ser compreendida, o português, sim ele mesmo, costumo dizer que de todas as linguagens, o português é a mais complexa, pois diferente das linguagens de programação que são claras e diretas, o português possui interpretação.
O DDD nos ajuda a diminuir esse ruido, aproximando cada vez mais a implementação técnica, do modelo de negócio.
Vamos entender um pouco melhor como ele funciona.
Conceitos
Para começar a falar de DDD precisamos ter muito claro alguns conceitos, pois sem eles todo o resto tende a dar errado.
O DDD é quebrado em três pilares:
- Linguagem Ubíqua
- Bounded Contexts
- Context Maps
Se procurarmos na literatura (Livro: Domain-Driven Design – Eric Evans) ou até mesmo em artigos no Google, a sequencia da explicação vem na ordem listada acima, porém pedirei licença aos criadores para inverter um pouco essa ordem.
| Bounded Context |
Esse pilar tem o intuito de delimitar, definir onde começa e onde termina um determinado contexto.
Vou começar por esse pilar, pois acredito que ele seja o principio de tudo, e o mais crucial para o sucesso da sua operação, a partir dele você consegue imaginar uma divisão de equipes e de microsserviços, facilitando as próximas conversas.
Para delimitar um contexto é necessário um entendimento claro do seu negócio, o contexto completo do que toda a sua plataforma irá atender. Muitos falham nessa definição, pois ela é extremamente interpretável, e depende do ponto de vista aplicado.
É um erro comum falhar na definição do contexto por olhar apenas um pedaço do negócio, e não ele como um todo.
Para uma definição correta de contexto é importante contar com a ajuda de pessoas com muito conhecimento do negócio, chamadas também de “Domain Expert”.
Vamos imaginar uma definição de contexto no App Waze
Nesse exemplo podemos ver uma clara divisão de contextos, sem sobreposição e com limites definidos.
Para ajudar a fechar o “escopo” de cada contexto, o próximo tópico (Linguagem Ubíqua) é fundamental, vamos a ele.
| Linguagem Ubíqua |
Agora é o momento de definição da linguagem comum de negócio, esse é o momento de pacificar e normalizar os nomes das coisas. Normalmente esse conceito é apresentado primeiro, mas eu prefiro aborda-lo após a definição de contexto, pois ajuda a dividir a discussão entre vários times e facilita o entendimento.
Por exemplo, imagine no caso o Waze o cliente, pode ser o usuário que acessa o mapa para se deslocar, como pode ser também o cliente que faz anuncio do seu produto dentro do aplicativo, isso vai depender um pouco do contexto em que você está inserido. Quando debatemos a Linguagem Ubíqua no contexto genérico da empresa fica mais difícil normalizar as nomenclaturas pois elas podem ter um diferente entendimento dentro de cada contexto detalhado.
Você deve estar se perguntando, mas nesse cenário de cliente, na hora de codar eu terei a mesma entidade em diversos contextos? Vou ficar duplicando código?
Bom, se acalme, você não vai replicar código, pois no caso demonstrado é possível notar uma clara diferença de regras e comportamentos que irão se desdobrar, ou seja, uma coisa nada tem a ver com a outra, apenas o conceito de cliente que é compartilhado, mas o comportamento na plataforma será diferente, não categorizando uma duplicação de código.
Vamos ao nosso próximo conceito.
| Context Map |
Bom, agora que você já tem seus contextos definidos, e a linguagem de trabalho normalizada, o próximo passo é entender como as coisas se relacionam.
A ideia do contexto map é pensar de forma estratégica como seus contextos vão coexistir na plataforma.
Voltando no desenho anterior, podemos ver agora a categoria de cada contexto, onde os azuis representam o domínio principal do seu negócio, o CORE dele. Definimos por domínio principal aquele contexto que se não existir, acaba com o propósito do seu negócio.
No nosso cenário, imagine o Waze sem mapas, não faz muito sentido correto, agora se pensarmos nos alertas de radar ou problemas na pista, sem isso o Waze ainda faz sentido, ou seja, esse é claramente um domínio genérico.
Depois de classificados os domínios, podemos ver como eles devem se correlacionar.
Domínios principais devem se relacionar com os domínios genéricos com o conceito de cliente – fornecedor, onde o domínio genérico assume papel de cliente, e deve se adequar a mudanças no fornecedor.
Em uma relação de domínio genérico com outro domínio genérico, devemos avaliar qual dos domínios deve ser superior ao outro, olhando caso a caso, e atuando com o conceito de conformismo, ou seja, nem sempre um terá maior relevância do que o outro, e por esse motivo não é incomum a discussão final chegar ao ponto de conformismo por menor impacto ou algum outro fator.
Quais os benefícios?
Bom conforme falamos no começo desse artigo, a utilização do DDD diminui o atrito, ou ineficiência entre entendimento de negócio e tecnologia. Ajuda também na organização dos times, definindo contextos específicos e diminuindo o atrito de escopo entre estes no dia a dia. Apoia também na definição macro da plataforma, com direcionadores pré definidos, diminuindo a chance de uma arquitetura mal pensada.
Armadilhas
Implementar DDD é extremamente difícil, e cansativo. São necessárias diversas conversas e muita paciência para fechar o entendimento entre todos os envolvidos.
Não é possível definir os pilares acima com pressa, é necessário tempo e tranquilidade para essa definição, se você tentar acelerar a definição, possivelmente algo ficará de fora.
Curtiu? Compartilhe esse conteúdo com seus amigos e equipe.
Quer ver ainda mais dicas de tecnologia? Me siga no insta @natanpf.
Até semana que vem.
Quer aprender mais? Siga o @devfullcycle, ele possui um conteúdo muito rico sobre esse assunto.
Natan Pasquarelli Freitas
Deixe uma resposta