Um bate-papo sobre DDD
Autor: Marcus Miris | Publicado: 2016-08-12T18:02:00-03:00

O texto abaixo foi escrito por Robson Castilho.
Link para o post 
original: https://robsoncastilho.com.br/2016/06/03/um-bate-papo-sobre-ddd/


Cara, estou trabalhando num projeto DDD!!

“Projeto DDD”? Bacana. Que negócio é esse?

Então…. tem uma separação em 4 camadas (Presentation, Application, 
Domain e Infrastructure) e um negócio de manter o ‘Domain’ separado de 
detalhes técnicos, como persistência.

Hmmm..arquitetura em camadas…e o que mais?
Uma série de patterns legais, como Value Object, Repository e 
Dependency Injection. Está sendo um desafio e tanto configurar tudo 
certinho no container de DI. Dá um certo trabalho entender com isso 
funciona.

Legal. E o que mais tem nesse DDD? Aliás, o que significa essa sigla?
A sigla significa Domain-Driven Design. Mais uma porção de coisas, 
como utilizar interfaces para desacoplar as camadas e também o uso do 
Entity Framework como ORM para cuidar da persistência dos objetos.
É outro grande desafio entender e configurar corretamente o Entity 
para lidar com o mapeamento dos objetos, lazy/eager loading, 
migrations,…. estou aprendendo bastante!

Imagino mesmo. Parece bem interessante. Me fala mais 
sobre o ‘Domain’. Ainda não tô entendendo onde isso tudo se relaciona 
com o nome ‘DOMAIN DRIVEN DESIGN’….
(Pensativo) Hmmm…bem…o ‘Domain’ é a camada onde ficam as 
regras de negócio. Nela, estamos usando o chamado ‘Modelo Rico’, ou 
seja, trabalhamos com um modelo orientado a objetos e, como eu disse 
antes, nosso ‘Domain’ é totalmente ignorante de detalhes de 
infraestrutura, ele só conhece as regras de negócio.

Isolar o que o seu software É (a área de conhecimento
 que ele atende) de detalhes técnicos, frameworks, databases, é uma 
ótima prática, sem dúvidas. Digamos que isso seja “implementar sua 
arquitetura de forma correta”, como, há décadas, explanado por diversos 
autores (vide ‘Ports and Adapters’, ‘Onion Architecture’, ‘Clean 
Architecture’ e similares).
E quem teve a ideia de utilizar DDD neste projeto?

Nós mesmos (os devs)!

E por que escolheram DDD?

(Pensativo) Bom, vimos na comunidade que muita gente está 
falando sobre o assunto, como uma boa prática. Estamos pensando em 
iniciar outro projeto com DDD também.


(Ficando preocupado) E do que se trata esse novo projeto?

É um projeto ASP.NET Web API. Já estamos estudando como usar DDD com ele.

(Notando que o buraco está ficando maior) Cara, 
estamos falando de muitas tecnologias e termos técnicos, mas, até o 
momento, não citamos muitos conceitos cruciais do DDD, sabia? Você já 
leu o livro do Evans? Alguém do projeto tem alguma experiência com DDD?
(Confuso) Não. Estou querendo comprar. Estamos seguindo 
alguns artigos e códigos de exemplo. E estamos todos aprendendo sobre o 
assunto neste projeto. Que pontos cruciais são esses? Então, você já 
sabia o que era DDD, né espertinho?

Sim. Estava te testando!! Faz 7 anos que estudo e 
pratico DDD. Aprendi bastante coisa e fiz inúmeras bobagens também, 
então, acho que sei um pouquinho sobre esse negócio.
Sinta-se tomando a pílula vermelha, ok?
OK!

Vamos lá! Tecnologias são importantes (e podemos 
bater um papo sobre elas em outro momento), mas tenho notado que DDD tem
 sido mencionado na comunidade como uma espécie de tecnologia – Web API +
 DDD, ASP.NET + DDD, TDD + DDD e
 similares – e as conversas sempre acabam indo para o lado de 
ferramentas (ORM), padrões (DI, Repository) e arquitetura (camada disso 
ou daquilo).
Isso me deixa bem preocupado. Preocupo-me pela possibilidade de 
estarem “usando DDD” por “estar na moda”, esquecendo-se daqueles tais 
pontos cruciais que mencionei…
Que seriam…?

DDD é um conjunto de práticas com o objetivo de construir um software de qualidade, que atenda as necessidades do cliente. Junto dessas práticas, temos a importância de trabalharmos próximos aos domain experts (pessoas da área de negócio que possam compartilhar conhecimento com os devs), entendendo a área de negócio do cliente e quebrando o problema em problemas menores.
Nesse processo, identificamos o core business do cliente e 
sub-áreas de negócio de menor importância, e podemos dar maior foco ao 
core business.
Foco no que importa mais para cliente -&gt; Entregamos mais valor -&gt; Melhor retorno sobre o investimento para o cliente!
Temos, aqui, conceitos como “Ubiquitous Language”, “Subdomains” e
 “Bounded Contexts” e diversas práticas em nível estratégico para 
trabalharmos com vários times, cada um atendendo uma parte do negócio.
No DDD, o foco está no domínio, que é a área de conhecimento para a qual você está criando uma solução, e na abstração deste domínio em 1 ou mais modelos, que resolvem problemas daquele domínio.
Tudo que mencionei agora são elementos fundamentais no DDD.

(Fazendo uma cara de “que conversa é essa?”)

Claro, ainda é software, e acaba sendo inevitável entrarmos em detalhes técnicos.
O Evans fala sobre arquitetura em camadas (as 4 das quais você 
falou no início da conversa) e também sobre patterns para ajudar no 
design do domain model (Entities, VOs, Services, etc..), os chamados 
“Building Blocks” do DDD.

Em livros mais recentes de DDD, fala-se mais ainda sobre 
implementação e arquitetura, entrando em práticas de integração (REST, 
messaging), CQRS/Event Sourcing, etc. Com isso, os autores pretendem 
entrar em algo mais prático, de modo que os leitores tenham uma ideia de
 como implementar o software seguindo os princípios do DDD. Assim, o 
assunto não fica extremamente abstrato e cansativo, como em muitas 
partes do livro do Evans.
No entanto, mesmo estes livros que focam bastante em código e integração, não se esqueceram dos pontos cruciais do DDD.
Hmm…

Veja, no início, também cometi muitos erros. Um dos 
principais erros era focar bastante no “micro”, o design do modelo e os 
padrões (Entities, VOs e afins), e esquecer do “macro”, identificar os 
subdomains e delimitar os contextos.
O domínio de uma técnica só vem através de EXPERIÊNCIA, o que não
 se ganha da noite para o dia. Com isso, chegamos à minha segunda 
preocupação com essa “moda do DDD”, se você ainda estiver com tempo de 
me ouvir…
Pode falar!

Um time inexperiente pode não dar muita atenção ao 
que eu disse sobre os pontos cruciais. É normal que a “gurizada”, como 
você (não se sinta ofendido), foque em aprender a usar as libs e 
frameworks do momento, sem se perguntar muito se aquilo resolve o 
problema. 
DDD possui um conjunto grande de práticas, que servem para 
resolver um problema complexo. Entender e aplicar DDD corretamente não é
 o mesmo que aprender a usar aquela lib de data binding.
Minha preocupação é estarem iniciando projetos tentando aplicar 
DDD e estarem criando aberrações. DDD foi feito para simplificar e não 
complicar o que é simples! 
Sendo assim, é fundamental que o time seja experiente e esteja extremamente empenhado em aprender DDD e entender o negócio.
 Por “time experiente”, entenda que seja um time onde haja, no mínimo, 
um líder que possa guiar o restante. Quanto maior e mais complexo o 
problema, mais necessária a presença de outros devs seniors.
E claro, a presença de Product Owners/Analistas de Negócio experientes também é fundamental.
Captou?
Acho que sim, e você me deixou com medo! Temos muitos problemas técnicos e nem todos são tão empenhados assim em estudar….

Desculpa, cara. Minha intenção não era te assustar ou
 ainda insinuar que vocês não são capazes. A intenção é ALERTÁ-LO a 
respeito das coisas que eu mencionei anteriormente. 
Fazer software não é algo trivial e bobo. É preciso agir e tomar 
decisões com responsabilidade (afinal, alguém está pagando por ele e 
esperando por um ótimo produto).
Dá uma refletida no assunto e, se quiser, estou à disposição pra conversarmos mais em outros momentos.
OK. Irei pensar sim! Vou processar tudo que você falou e, com certeza, iremos trocar uma ideia!

Será um prazer!
E não esqueça que DDD é simplificar, é entregar valor pro seu 
cliente com uma solução altamente alinhada com a área de negócio dele.
Eu não entrei em muitos detalhes – e até várias outras disfunções
 encontradas quando falamos sobre DDD – mas ocasiões não irão faltar!
Com certeza. A gente se fala! Até mais e muito obrigado pelas dicas!

“Que isso”! Até!