O DDD tornou-se um tema altamente debatido e naturalmente uma série de equívocos surgiram através dos diferentes entendimentos sobre o assunto.

Vou citar algumas perguntas / afirmações que venho observando faz alguns anos e são a minha principal motivação para escrever este post.

• Como faço para persistir uma entidade com Entity Framework no DDD?
• Como faço para popular um DropDownList seguindo o padrão DDD?
• Iniciei um novo projeto em MVC + DDD na minha empresa e tenho uma dúvida.
• Estou criando um back-end em WebAPI + DDD
• Onde coloco uma camada de cache num projeto DDD?
• Existe algum framework de DDD em .NET?

DDD não é arquitetura em camadas.

O DDD é uma abordagem de modelagem de software que segue um conjunto de práticas com objetivo de facilitar a implementação de complexas regras / processos de negócios que tratamos como domínio.

Domain Driven Design como o nome já diz é sobre design. Design guiado pelo domínio, ou seja, uma modelagem de software focada em resolver problemas na complexidade do negócio.

“Toda arquitetura é design, mas nem todo design é arquitetura” – Grady Booch

O DDD não é uma receita pronta sobre como desenvolver uma arquitetura baseada em Presentation, Services, Application, Domain e Infra.

DDD não é tecnologia.

O DDD não depende da tecnologia que você irá utilizar para fornecer sua aplicação seja ela ASP.NET MVC, WebAPI, SPA, Windows Forms ou etc.

O DDD não irá influenciar em diversas decisões:

• Como preencher um controle na camada de apresentação
• Como expor uma API REST
• Qual tecnologia usar para persistir os dados
• Como realizar o deploy da aplicação
• Como modelar seu banco de dados
• Como trabalhar com camadas de Infra (ex. Cache, Log, IoC)
• Qualquer outra decisão de tecnologia.

Evite as gafes

Evite utilizar o termo DDD acompanhado de questões que não envolvem diretamente os conceitos do DDD, pois pode dar a entender que você não compreendeu sobre do que se trata o assunto.

Então do que se trata o DDD?

O DDD resgatou e catalogou uma série de boas práticas que foram ignoradas durante anos na maioria dos projetos e na minha opinião esta é a maior conquista do autor na concepção da sua ideia.

Eric Evans em seu livro aborda desde o primeiro capítulo a preocupação no entendimento do negócio, pois entender e destilar o negócio é o único meio de implementar o DDD em um projeto.

Não existe um modelo passo-a-passo de como implementar o DDD, mas podemos tentar criar um resumo básico:

Passo #1 – Entender o Negócio

Sem entender o negócio não tem como implementar o DDD. Em um projeto existem basicamente dois tipos de papéis, o Time de Desenvolvimento e os Domain Experts.
Os Domain Experts entendem do negócio e vão guiar o time de desenvolvimento no projeto tirando dúvidas, definindo regras e processos e nomeando os termos a serem utilizados.

Passo #2 – Extrair a Linguagem Ubíqua

A Linguagem Ubíqua é uma linguagem compartilhada e desenvolvida pela equipe de Domain Experts e de Desenvolvimento. A Linguagem Ubíqua é a linguagem do negócio dentro da empresa e todos devem fazer uso dela para expressar corretamente todos processos / intenções de negócio.

Existem diversas técnicas para extrair e catalogar a Linguagem Ubíqua, cabe ao time definir a melhor maneira de colaborar.

Passo #3 – Modelagem Estratégica

Extrair a Linguagem Ubíqua vai colaborar na visão e entendimento do negócio e como segregar seu domínio em partes menores e responsáveis.

Para documentar estas segregações responsáveis utilizamos o Mapa de Contextos (Context Map) que pode ser representado através de imagens e uma simples documentação do tipo de relacionamento entre os contextos.

Além de delimitar os contextos a modelagem estratégica engloba outros conceitos como  Sub-Domain, Shared Kernel, Customer/Supplier, Conformist, Anti-Corruption Layer, Separate Ways, Open Host Service e Published Language.

Cada contexto delimitado possui sua própria Linguagem Ubíqua, para entender melhor estes conceitos eu escrevi um artigo falando sobre os Bounded Contexts.

Nota: Eu acredito que não existe uma forma de implementar o DDD sem aplicar os conceitos da modelagem estratégica. Inclusive o próprio Eric Evans comentou que se ele fosse escrever seu livro nos dias de hoje ele teria começado pelo conceito de Bounded Contexts.

Passo #4 – Definir a Arquitetura

Tendo uma clara visão do Context Map é possível trabalhar na definição da arquitetura.

Cada contexto pode possuir uma arquitetura independente dos demais, não é necessário impor o mesmo estilo arquitetural para todos os contextos.

O DDD não prega a necessidade de uma arquitetura de 4 camadas (Presentation, Application, Domain e Infra). Pelo contrário, o arquiteto tem a liberdade de definir o melhor estilo arquitetural para atender a necessidade da aplicação, podendo utilizar modelos simples de 3 camadas como o Table Module Pattern.

Existem diversos estilos arquiteturais como a clássica Arquitetura Cebola, Arquitetura Hexagonal proposta pelo Vernon em seu livro Implementing Domain Driven Design ou até mesmo os populares Microservices. Alguns destes estilos inclusive podem fazer uso de patterns como CQRS, Event Sourcing, etc.

Um arquiteto deve conhecer os estilos e patterns arquiteturais e saber reconhecer onde e quando devem ser utilizados.

Passo #5 – Modelagem Tática

Quando o assunto é DDD a modelagem tática fica por conta do Domain Model Pattern que é uma abordagem de como escrever as classes que vão mapear os modelos do mundo real e implementar os comportamentos do negócio.

O Domain Model Pattern deve ser isolado dos detalhes da sua arquitetura como persistência e etc.

O Eric Evans não criou os patterns utilizados no Domain Model, apenas fez o uso correto deles criando então esta abordagem de modelagem tática que incluem os seguintes componentes:

• Aggregate Object
  Uma entidade que é a raiz agregadora de um processo do domínio que envolve mais de uma entidade.
• Domain Model
  Uma entidade do domínio, possui estados e comportamentos, lógica de negócio, getters e setters AdHoc, etc.
• Value Object
  Um objeto que agrega valor às entidades, não possui identidade e é imutável.
• Factory
  Classe responsável por construir adequadamente um objeto / entidade.
• Domain Service
  Serviço do domínio que atende partes do negócio que não se encaixam em entidades específicas, trabalha com diversas entidades, realiza persistência através de repositórios e etc.
• Application Service
  Serviço de aplicação que orquestra ações disparadas pela camada de apresentação e fornece DTOs para comunicação entre as demais camadas e para o consumo da camada de apresentação.
• Repository
  Uma classe que realiza a persistência das entidades se comunicando diretamente com o meio de acesso aos dados, é utilizado apenas um repositório por agregação.
• External Service
  Serviço externo que realiza a consulta/persistência de informações por meios diversos.

Se você trabalhou em todos os passos citados, parabéns! Você provavelmente está implementando o DDD. Fique a vontade para utilizar técnicas como TDD e BDD e sinta-se livre para escolher a plataforma da camada de apresentação ou como distribuir suas API’s etc. Afinal este não é o foco e nem uma exigência do DDD.

Quando devo utilizar o DDD?

Apesar de muitas pessoas afirmarem utilizar DDD apenas por possuir uma arquitetura em camadas isto não significa que realmente estejam usando o DDD, existem algumas interpretações como DDD-Lite que seria uma aplicação utilizando alguns conceitos encontrados no DDD porém ignorando muitos outros.

Uma analogia a este cenário seria um time de desenvolvimento dizer que utiliza Scrum como uma metodologia de desenvolvimento ágil quando somente faz uso de um quadro Kanban e ignora as práticas de sprints, cerimônias etc. Nós chamamos isto de ScrumBut.

Espero que tenha ficado claro até este ponto o que é realmente o DDD e os passos principais para implementá-lo. Para saber se você deve ou não implementar o DDD no seu projeto, disponibilizo abaixo um DDD Score Card extraído do livro Implementing Domain Driven Design.

A ideia é bem simples, a primeira coluna descreve seu projeto, em seguida o número de pontos que devem ser acumulados, a última coluna descreve algumas concepções.
Se no final a somatória dos pontos for igual ou maior que 7 considere seriamente em implementar o DDD em seu projeto.

Ao finalizar este exercício você terá mais clareza para determinar se o DDD é viável ou não para o seu projeto. Lembre-se de tomar as decisões com foco na simplicidade, entrega e manutenção. Muitas vezes sofremos da vontade incontrolável de implementar todos os conceitos de nossos estudos, porém estamos colocando em risco o dinheiro da empresa e nossa própria carreira.

Erros comuns

Agora que está muito claro o que é o DDD e se ele é viável para seu projeto, gostaria de alertar sobre os erros mais comuns cometidos pela maioria dos desenvolvedores.

#1 – Permitir que o meio de persistência influencie diretamente nas entidades.

Quando utilizamos ORM’s para mapear o banco e nossas entidades muitas vezes somos obrigados a “infectar” nossos modelos com necessidades do ORM utilizado. Evite ao máximo tomar decisões que impactem em suas entidades e que no final servem apenas para atender as necessidades do meio de persistência.

 #2 – Não se envolver com os Domain Experts

Ignorar o conhecimento de negócio dos Domain Experts é uma falha grave, busque envolvê-los diretamente no projeto e nas decisões. Documentar alguns processos com BDD é uma ótima maneira de aproximar todos os envolvidos em uma conversa fluente e clara.

Se na sua empresa não existe o “Domain Expert” não tem problema, com certeza existe alguém que conheça bem do negócio, traga esta pessoa para participar ativamente no projeto.

#3 – Ignorar a Linguagem Ubíqua

A Linguagem Ubíqua é a linguagem do negócio, deixar de extraí-la e mapeá-la poderá acarretar em sérios problemas de comunicação que irão refletir diretamente no entendimento dos requisitos e no código fonte. Será um grande problema no futuro.

#4 – Não identificar os limites dos contextos

Pular a parte da modelagem estratégica é um dos maiores erros que se pode cometer ao implementar o DDD. Isto tornará sua aplicação extremamente complexa e monolítica, é o princípio de uma grande bola de lama (Big Ball of Mud).

#5 – Escrever entidades anêmicas

O uso de entidades anêmicas é sinal de uma grande falta de entendimento no comportamento de uma entidade, quebra o próprio conceito da OOP que diz que um objeto deve possuir estados e comportamentos. Uma entidade no mínimo deve saber se auto-validar para garantir sua consistência, logo não existem motivos para escrever entidades anêmicas.

#6 – Assumir que toda lógica é lógica de domínio 

Nem toda validação é responsabilidade do domínio. Por exemplo o tratamento de acesso e permissões de usuário, isto é responsabilidade da aplicação. Deixar todas as validações por conta do domínio também é uma falha, num cenário Web a camada de apresentação também pode realizar as validações necessárias para filtrar as requisições no servidor.

#7 – Focar demais na infra-estrutura

Implementar um projeto com DDD significa trabalhar com foco no negócio, iniciar o projeto pela modelagem do banco de dados e preocupando-se com os meios de persistência são erros que podem pode gerar impactos negativos nos seus modelos de domínio. A camada de infra-estrutura serve para suportar responsabilidades que não são do domínio, foque nas implementações de infra-estrutura conforme a necessidade surgir.

Resumindo

Implementar o DDD em seu projeto pode ser uma ótima decisão que proporcionará mais facilidades para atender aos complexos processos de negócio. Tornará a equipe mais colaborativa e focada no que é realmente mais importante.

Não se aventure no escuro! Antes de iniciar um projeto em DDD é necessário ter um bom conhecimento teórico e prático em todos os conceitos abordados neste artigo. Eu recomendo fortemente a leitura de livros, cursos e demais conteúdos que irão lhe preparar para que este desafio não se torne um grande desastre.

E por fim evite de utilizar o DDD como referência para arquitetura em camadas, agora você já sabe que não é disto que se trata o DDD.

Caso esteja interessado em conhecer mais sobre o DDD, Padrões de Arquitetura como CQRS, Event Sourcing e boas práticas de desenvolvimento não deixe de conferir a ementa do meu curso:

• Curso de Arquitetura de Software .NET

Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

Bounded Context é um conceito muito importante do DDD e pode ser a solução para a boa modelagem do seu domínio.

Bounded Context é um conceito tão importante quanto o entendimento da separação de responsabilidades das camadas do DDD. Você tem utilizado este conceito em sua aplicação? Cuidado! Você pode estar construindo uma grande bola de lama.

Bounded Context é um conceito razoavelmente fácil de se explicar, porém pode ser extremamente complexo de se implementar. Tudo depende da visão global do domínio da aplicação.

O que significa visão global do domínio?
Ter uma visão global significa enxergar toda a extensão de seu domínio e eu não estou me referindo as camadas, estou me referindo ao negócio.

Como ter uma visão global do negócio se a aplicação ainda não foi desenvolvida ou está em processo de desenvolvimento?
É necessário lutar contra a IVSF “Irresistível Vontade de Sair Fazendo” e focar antes em mapear seus contextos e definir os Bounded Contexts “contextos delimitados”. Para determinar seus Bounded Contexts você precisa ter um bom conhecimento do negócio da empresa ou ter ao seu lado um Domain Expert.

Domain Expert

É a pessoa que entende do negócio da empresa e vai apoiar os times de desenvolvimento na modelagem do domínio, definição das regras de negócio e etc. O domain expert também é responsável por definir a Ubiquitous Language “Linguagem Ubíqua”.

Context Map

Para a aplicação ter um bom design, uma fácil manutenção / extensibilidade e o domínio ser bem modelado é necessário focar em modelagem estratégica e para isso é importante preocupar-se com a integridade do modelo conforme o diagrama do Context Map apresenta.

Todos os conceitos do Context Map são importantes, é necessário compreender muito bem de cada um deles para termos condição de realizar uma boa modelagem.

Big Ball of Mud

A grande bola de lama. Você pode ter uma em suas mãos neste momento.
Este conceito aborda vários aspectos negativos de sua aplicação, desde código macarrônico que fere os princípios do SOLID e Clean Code até uma entidade com muitas responsabilidades em um único contexto. Analise a imagem a seguir:

A entidade Produto possui diversos comportamentos, cada um destes comportamentos está ligado a uma intenção da aplicação, todas as intenções são relativas ao produto em si, porém imagine a complexidade desta classe, quantas equipes de desenvolvimento estão compartilhando a mesma classe em comum.
A entidade Produto atende aspectos de Aquisição, Venda, Entrega, Estoque e etc.
Esse tipo de modelagem pode ser considerada um exemplo de Big Ball of Mud, pois qualquer manutenção nessa entidade pode ocasionar impactos sérios em diversos pontos da aplicação, é praticamente impossível de gerenciar as mudanças.

Como resolver ou evitar este tipo de cenário?
O DDD não é sobre dividir a aplicação em camadas responsáveis, o DDD é sobre modelar corretamente o domínio do seu negócio. Se sua aplicação possui uma única camada de domínio e esta camada concentra todas as entidades do seu negócio você pode estar cometendo um grande erro de modelagem de domínio. Para aplicações que possuem domínios muito complexos o ideal é aplicar o conceito de Bounded Context.

Bounded Context

Os contextos delimitados ou bounded contexts buscam delimitar o seu domínio complexo em contextos baseados nas intenções do negócio. Isto significa que você deve delimitar as intenções de suas entidades com base no contexto que ela pertence. Analise a imagem a seguir:

O domínio foi subdividido em seis pedaços, ou melhor, em seis bounded contexts, um para cada intenção de negócio (Vendas, Entregas, Estoque etc.). Agora cada bounded context possui uma entidade Produto. Cada versão da entidade Produto é diferente nos seis bounded contexts existentes. A entidade Produto possui comportamentos que atendem necessidades específicas de seu bounded context, a única coisa em comum entre todas as entidades Produto é sua identidade, o ProdutoId no caso. A identidade em comum vai ajudar na persistência e na comunicação entre os bounded contexts.

Mudando um pouco de cenário imagine uma entidade chamada Funcionário, esta entidade representa o colaborador da empresa dentro da aplicação. No bounded context “Recursos Humanos” a entidade Funcionário possui uma modelagem que atende comportamentos como férias, salário, rescisão etc. No bounded context “TI” esta entidade possui uma modelagem que atende comportamentos como login, troca de senha, permissões etc.

Quando se pergunta sobre um funcionário no departamento de TI este está ligado a um usuário e suas responsabilidades dentro do sistema, quando se pergunta sobre um funcionário dentro do RH este está ligado a um colaborador da empresa. É a mesma pessoa, porém dentro da aplicação possui intenções diferentes e é baseada nas intenções que o seu domínio deve ser delimitado em contextos. Não tem necessidade nenhuma a entidade Funcionário do o bounded context de TI ter acesso a salário, reajustes e etc.

Os Bounded Contexts fornecem aos membros das equipes de desenvolvimento um claro entendimento do que deve ser consistido e desenvolvido independentemente.

Representar a mesma entidade em diversos bounded contexts não seria duplicar o código?
De forma alguma. Duplicar código é ter a mesma responsabilidade em trechos de código diferentes. Neste caso existe uma segregação de comportamentos e intenções de uma entidade conforme o contexto em que ela está. Não importa se a entidade é persistida na mesma tabela ou em tabelas diferentes, neste caso ambos os cenários são aceitos.

Características importantes de um bounded context

• Cada bounded context pode possuir sua própria abordagem de arquitetura. Camadas de aplicação, persistência, infra-estrutura e etc.
• A arquitetura de um bounded context não precisa estar necessariamente no padrão DDD (Domain Model) pode ser um modelo mais simples de 3 camadas, pode implementar CQRS, Event Sourcing e etc.
• Cada bounded context pode possuir um meio próprio de persistência, sendo ele relacional, NoSQL, em memória / cache e etc.
• Os bounded contexts podem se comunicar entre si de diversas maneiras, inclusive utilizando eventos de domínio “Domain Events” conectados em um “Event Bus”.
• Cada bounded context possui sua própria Ubiquitous Language.
• Cada bounded context pode ser desenvolvido por um time de desenvolvedores diferente. Não existe necessidade de um único time conhecer a implementação de todos os contextos, pelo contrário, por motivos de segurança o fonte de um bounded context pode ser restrito a um time específico.

Patterns de relacionamento entre bounded contexts

Existem diversos patterns que descrevem o tipo de relacionamento entre os bounded contexts:

• Shared Kernel
  Um contexto compartilhado entre outros contextos, o shared kernel é um tipo de contexto onde N bounded contexts dependem dele, uma espécie de Core, este tipo de contexto não pode ser alterado sem consultar todos os times de desenvolvimento que dependem dele.
• Customer/Supplier
  Contextos customer dependem de contextos supplier.
  A equipe downstream atua como cliente (customer) da equipe upstream (supplier). As equipes definem testes de aceitação automatizados que validam as interfaces que a equipe upstream fornecem. A equipe upstream pode então fazer alterações em seu código sem medo de quebrar alguma coisa da equipe downstream.
• Conformist
  É o cenário onde as equipes downstream e upstream não estão mutuamente alinhadas e a equipe downstream precisa atender o negócio com o que a equipe upstream fornece mesmo não estando de acordo com as necessidades. A equipe downstream precisa aceitar este fato, se conformar com isto.
• Partner
  Neste cenário duas equipes possuem dependências mútuas em seus contextos e precisam somar esforços de modelagem para se atenderem mutuamente.
• Anti Corruption Layer
  Neste cenário a equipe downstream desenvolve uma camada adicional anti-corrupção para se comunicar com o contexto upstream, é o cenário típico onde o supplier é um sistema legado ou uma API mal desenvolvida.

Domain Model Pattern

É um padrão muito indicado para atender um bounded context, o domain model pattern atende diversas convenções do DDD como:

• Aggregate Object
  Uma entidade que é a raiz agregadora de um processo do domínio que envolve mais de uma entidade.
• Domain Model
  Uma entidade do domínio, possui estados e comportamentos, lógica de negócio, getters e setters AdHoc, etc.
• Value Object
  Um objeto que agrega valor às entidades, não possui identidade e é imutável.
• Factory
  Classe responsável por construir adequadamente um objeto / entidade.
• Domain Service
  Serviço do domínio que atende partes do negócio que não se encaixam em entidades específicas, trabalha com diversas entidades, realiza persistência através de repositórios e etc.
• Application Service
  Serviço de aplicação que orquestra ações disparadas pela camada de apresentação e fornece DTOs para comunicação entre as demais camadas e para o consumo da camada de apresentação.
• Repository
  Uma classe que realiza a persistência das entidades se comunicando diretamente com o meio de acesso aos dados, é utilizado apenas um repositório por agregação.
• External Service
  Serviço externo que realiza a consulta/persistência de informações por meios diversos.

E o código como fica?
O mais importante é entender os conceitos, uma vez que cada um deles estão claros escrever o código é a parte mais fácil. Num próximo material eu trarei uma implementação destes conceitos.

Resumindo

O conceito de bounded context deve ser aplicado buscando delimitar os comportamentos do domínio com base em suas intenções, dando claro entendimento do que precisa ser desenvolvido de forma independente e compartilhada.

Trabalhar com DDD não significa abordar uma arquitetura dividida em camadas responsáveis sendo uma delas a camada de domínio, significa trabalhar a complexidade do negócio em uma modelagem que atenda as necessidades de forma clara, coesa e respeitando as boas práticas de desenvolvimento.

Vaughn Vernon em seu livro Implementing Domain-Driven Design aborda o conceito de arquitetura hexagonal utilizando DDD, CQRS, Event Sourcing, Domain Events, SOA e etc. Neste livro é possível entender que cada bounded context pode possuir sua própria arquitetura hexagonal ou implementar alguma outra abordagem de arquitetura como já foi citado anteriormente neste artigo.

O DDD desde 2003 vem evoluindo bastante e já não está mais preso nos conceitos iniciais, está mais aberto e flexível, permitindo diversas abordagens de arquitetura entre outras implementações como eventos e mensagerias para integrações.

Referências

• Eric Evans – DDD
• Domain Driven Design Quickly
• Vaughn Vernon

Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações com uma arquitetura responsável utilizando DDD, TDD, BDD, aplicando os princípios SOLID, diversos design patterns e escrevendo testes de unidade conheça meus cursos:

• Cursos de Arquitetura e Desenvolvimento Web

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.