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
- Meu artigo sobre DDD publicado, há 2 anos, na revista Engenharia de Software – uma introdução um pouco mais detalhada do que este artigo.
- Os já citados livros: “Domain-Driven Design – Tackling Complexity in the Heart of Software” e “Implementing Domain-Driven Design”. Recomendadíssimos! O último é recente (de 2013), com muitos exemplos de código e com maior foco no design estratégico.
- O mini-book da InfoQ “Domain-Driven Design Quickly” assim como vários materiais disponíveis no site, tais como palestras e entrevistas com Eric Evans e outros nomes conhecidos do DDD.
………………………………………………..
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.
Participe! Vamos trocar uma ideia sobre desenvolvimento de software!