Domain-Driven Design Rápido e Rasteiro

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.

Participe! Vamos trocar uma ideia sobre desenvolvimento de software!

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Blog no WordPress.com.

Acima ↑

%d blogueiros gostam disto: