Um bate-papo sobre DDD

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 -> Entregamos mais valor -> 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é!