Entendendo a “complexidade do domínio”

Estudar DDD me levou a pensar mais sobre as complexidades de desenvolver e manter software. Junto com isso, surgiu a necessidade de aplicar algum tipo de classificação aos problemas que ajudo a resolver. Nisso, passei a utilizar três grupos principais de complexidades:

1. Complexidades da solução técnica, diretamente relacionadas com as escolhas das técnicas e tecnologias empregadas para o desenvolvimento de uma solução em software. Por exemplo, a decisão sobre que frameworks utilizar, utilizar um provedor de nuvem ou on-premises, etc;
2. Complexidades do legado, que nascem na base de software já desenvolvida e em produção que precisa ser mantida, pelo menos por um tempo, para continuar atendendo os objetivos do negócio. Delas são derivadas muitas das restrições que frequentemente dificultam a evolução das soluções;
3. Complexidades do domínio, relacionadas especificamente a natureza do problema que desejamos resolver utilizando o software. Uma complexidade do domínio não será reduzida pelo talento do desenvolvedor – a realização de cirurgias no cerebrais, por exemplo, não ficará menos complexa, independente do talento do time de desenvolvimento. No máximo, a complexidade será mitigada, jamais eliminada.

A importância de interagir BEM com especialistas de domínio

Pessoas de tecnologia têm facilidade e familiaridade natural com aspectos relacionados as complexidades da solução técnica e do legado. Entretanto tem muito menos facilidade com a complexidade do domínio. Isso justifica o envolvimento dos especialistas de domínio.

Um especialista de domínio é alguém com profundo conhecimento do problema de negócio que se está tentando resolver e que consegue ajudar o time técnico a entender o que precisa ser feito, gerando resultados mais efetivos.

Frequentemente, a comunicação entre especialistas de domínio e times técnicos não é das mais fáceis. A causa disso é que o vocabulário das partes é diferente. Afinal, gente de tecnologia está mais ambientada com expressões tecnológicas e especialistas do negócio são mais íntimos de termos do negócio. Quando não há cuidado, ninguém se entende.

Linguagem onipresente

O caminho para contornar as dificuldades de comunicação entre os times de tecnologia e os especialistas de domínio está em explicitar uma linguagem onipresente.

Hoje, quando se fala em DDD, parece ser natural ouvir desenvolvedores dando ênfase demasiada a entidades, objetos de valor, agregados, repositórios, especificações, etc. Por outro lado, é muito menos comum acompanhar discussões sobre alternativas reais para converter descrições feitas pelos especialistas de negócio, usando a linguagem onipresente, em código. O resultado são soluções anêmicas e rebuscadas que destroem valor no lugar de gerar.

DDD do jeito certo?

Esse é o início de uma longa jornada…

Nesse livro vamos buscar restaurar a essência de DDD. Vamos explorar formas efetivas de, verdadeiramente, utilizar a linguagem onipresente no código, que é o lugar onde os desenvolvedores realmente se importam.

De maneira consistente, vamos verificar como os padrões propostos por DDD ajudam a fazer com que a lógica do domínio, expressa pelos especialistas, esteja presente de maneira expressiva no design das soluções desenvolvidas.

// TODO

1. Reflita sobre sua experiência com DDD, caso tenha. Você deu ênfase às complexidades de domínio?
2. Como tem sido sua experiência lidando com especialistas de domínio? Eles tem envolvimento direto com seu time?