Neste artigo, veremos uma rápida introdução ao Domain-Driven Design, conceito criado por Eric Evans e consolidado em seu famoso livro azul “Domain-Driven Design – Tackling Complexity in the Heart of Software”, de 2003.

O assunto é bem denso e impossível de ser tratado em detalhes em um simples artigo de blog. Portanto, espero que este sirva ao menos como um start para futuros estudos sobre o tema (vale a pena!).

O QUE É DDD?

De forma mais sucinta possível, podemos dizer que Domain-Driven Design é um conjunto de práticas que tem por objetivo a construção de um software que expresse de forma bem clara o problema em questão. (Tecnicamente, estamos em busca de um domain model bem projetado.);

Um (rich) domain model é um conjunto de objetos interconectados, projetados para atender regras de negócio complexas, onde cada um deles tem um significado próprio dentro da área de negócio a ser atendida.

………………………………………………..

POR QUE DDD?

DDD faz sentido porque:

  • Alinha o conhecimento dos desenvolvedores e dos domain experts produzindo software mais coerente com o negócio.
  • O design É o código e não há traduções entre desenvolvedores e domain experts porque todos compartilham a mesma linguagem.
  • Fornece práticas em nível tático, na criação de um domain model sólido, e em nível estratégico, auxiliando na identificação das áreas mais importantes a serem atacadas e como essas áreas se comunicam.

………………………………………………..

QUANDO DDD?

São premissas básicas para o sucesso do DDD: o desenvolvimento iterativo e a comunicação constante com domain experts. Sem esses dois requisitos, fica muito difícil – senão impossível – entender o negócio de forma a criar um domain model coerente com o mesmo.

Mesmo que as premissas sejam (ou possam ser) atendidas, DDD será aplicável em sua plenitude quando:

  • O software irá atender uma área de negócio muito específica e complexa, onde ninguém ou poucos possuem conhecimento.
  • Há muitas operações de negócio (dezenas).
  • Há mudanças frequentes nas funcionalidades e regras.

DDD não fará sentido quando:

  • O software é um pequeno aplicativo de suporte da empresa, como, por exemplo, um software composto basicamente de alguns CRUDs ou uma API de consulta que basicamente busca alguns dados e os retorna em algum formato específico.

………………………………………………..

O VALOR DE NEGÓCIO DO DDD

O maior valor da prática está no foco no negócio principal da empresa, naquilo que é – ou pode ser – seu diferencial competitivo (chamado de Core Domain).

E mais vantagens como:

  • Troca de conhecimento entre desenvolvedores e domain experts, reduzindo as chances de que o conhecimento sobre o domain model fique nas mãos de poucas ou de uma única pessoa.
  • Melhor experiência de usuário, uma vez que as telas do software passam a refletir uma operação de negócio (ao invés de tudo se resumir a “cadastros”).
  • Código expressando melhor o negócio e arquitetura da solução melhor organizada.

………………………………………………..

LINGUAGEM UBÍQUA E BOUNDED CONTEXTS

A linguagem ubíqua é a linguagem criada pelo time de desenvolvimento em conjunto com os domain experts. Ela deve expressar o negócio em comunicação falada, em documentos, no próprio código, ou seja, em todo lugar (“ubíqua”).

Da forma mais correta, quando dizemos “em todo lugar” estamos nos referindo a um contexto específico – chamado de bounded context – que é uma fronteira conceitual onde reside o domain model e sua linguagem ubíqua.

Para deixar um pouco mais claro, pense no termo “Livro” como tendo um sentido em um contexto (como “obra literária”) e outro sentido em outro contexto (como um exemplar específico adquirido em uma loja).

………………………………………………..

DESIGN TÁTICO

DDD fornece uma série de conceitos e padrões que nos auxiliam no design da solução, tanto em nível tático como em nível estratégico.

Em nível tático, temos padrões que auxiliam na criação do domain model: Entidades, Value Objects, Serviços (de Domínio), Eventos (de Domínio), Aggregates, Repositórios, Factories.

É importante lembrar que esses padrões não foram criados junto com o DDD, embora muitas pessoas só tenham contato com eles através do DDD. Todos eles já eram padrões consolidados e apresentados em diversos livros de padrões, bem antes do “blue book” do Eric Evans.

É justamente pelo uso desses padrões que a maioria das pessoas começa com DDD e acaba emperrada neles, esquecendo de todos os demais conceitos do DDD. Essa prática limitada é chamada de “DDD-Light” por Vaughn Vernon, em seu livro “Implementing Domain-Driven Design”.

………………………………………………..

DESIGN ESTRATÉGICO

Em nível estratégico, temos padrões úteis para lidarmos com soluções muito complexas, compostas por vários sistemas, sejam internos ou externos. Além do próprio bounded context – já mencionado – somos apresentados aqui a conceitos como Sub-Domain, Context Map, Shared Kernel, Customer/Supplier, Conformist, Anticorruption Layer, Separate Ways, Open Host Service e Published Language.

Esses padrões nos fornecem ajuda para “quebrar” um modelo complexo em vários contextos e para integrá-los de uma forma organizada, ao invés de pensarmos em um modelo único e gigantesco para todo o negócio de uma empresa.

………………………………………………..

DDD E ARQUITETURA DE SOFTWARE

Costumo dizer que não concordo com o termo “Arquitetura DDD” porque – como espero que tenham notado até aqui – DDD não é um padrão ou estilo arquitetural. Os conceitos apresentados no DDD vão bem com diversos conceitos de arquitetura como arquitetura em camadas, hexagonal/cebola (*), REST, CQRS e Event-Driven.  (O importante é que o domain model mantenha-se isolado de detalhes técnicos.);

* Vejam meu artigo “Sobre camadas, cebolas e hexágonos”, onde falo mais sobre o assunto.

………………………………………………..

LEITURA ADICIONAL

………………………………………………..

CONCLUSÃO

Como enfatizado no título deste post, esta foi uma breve introdução ao DDD, onde procurei mostrar de forma bem rápida seus principais conceitos.

O assunto é muito mais amplo do que isso e convido vocês a lerem o material citado acima. O estudo do tema me proporcionou um grande amadurecimento como profissional.