Qualquer tolo inteligente consegue fazer coisas maiores e mais complexas. É necessário um toque de gênio — e muita coragem para ir na direção oposta.
Albert Einstein
Meu primeiro contato com Domain-driven Design aconteceu em 2006. Encontrei a primeira edição do livro azul, escrito por Eric Evans, em uma livraria montada na CeBIT – uma das maiores exposições de telecomunicações e TI do mundo – em Hannover. Lembro de “devorar” o livro, em uma primeira leitura rápida, durante as longas horas de voo retornando ao Brasil. A forma como penso desenvolvimento de software mudou, de maneira definitiva, desde então.
2
Quando foi seu primeiro contato com DDD? Como foi?x

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.

Domain-driven Design ajuda a mitigar as complexidades do domínio, não tratando, pelo menos de maneira direta, das complexidades relacionadas ao legado e as soluções técnicas.
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

Interessante observar que, dos três grupos de complexidades propostos, o “negócio” está disposto a “pagar” apenas pelas complexidades do domínio. Tanto a solução técnica quanto a manutenção do legado são “males necessários”.
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

Também é importante entender que apenas as complexidades relacionadas ao domínio não são opcionais em um projeto, são essenciais. Tanto as complexidades decorrentes do legado quanto das soluções técnicas são ditas acidentais pois decorrem, de uma maneira ou outra, das escolhas dos times de tecnologia.
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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.

O especialista de domínio deve ser alguém das “trincheiras” e, exceto em cenários muito raros, não será alguém do time de desenvolvimento, mas, sim, alguém que poderia ser um “usuário padrão” para o software que está sendo desenvolvido.
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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.

A linguagem onipresente é a mesma utilizada pelos especialistas de domínio, após removidas ambiguidades. Trata-se da essência de DDD.
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

O problema é que pessoas de tecnologia naturalmente se importam pouco com o conceito de linguagem onipresente. Não é raro encontrar gente que leu “por cima”, no livro azul, as considerações sobre o tema afim de chegar mais rapidamente aos padrões expressos em código e, fazendo isso, comprometem seu entendimento.
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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.

Desenvolvedores, apaixonados por complexidades de solução técnica tem transformado DDD em um cardápio de padrões técnicos, esquecendo do essencial. Isso é um erro!
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

DDD do jeito certo?

Utilizar DDD do jeito certo implica em reconhecer que seu propósito é atacar as complexidades do domínio, que são essenciais. Não é tratar das soluções técnicas, tampouco lidar com o legado.
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

Quando mais complexo for um domínio, maior será a aderência das técnicas propostas por Domain-driven Design. Se o software que se precisa desenvolver “resolver” complexidades de um domínio simples, então DDD agregará pouco valor. Tentar “empurrar” DDD em qualquer projeto é expressão de imaturidade ou de incompetência.
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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

Antes de avançar para o próximo capítulo, peço que concentre algum esforço nas seguintes atividades:
0
Que outras reflexões você acha que seriam adequadas aqui?x

  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?

 

Vídeo relacionado

Confira também o seguinte vídeo relacionado a este tema:

Compartilhe este capítulo:

Compartilhe:

Comentários

Participe da construção deste capítulo deixando seu comentário:

Inscrever-se
Notify of
guest
4 Comentários
Oldest
Newest Most Voted
Feedbacks interativos
Ver todos os comentários
Diogo
Diogo
3 anos atrás
Feedback no conteúdo deste capítulo Quando mais complexo for um domínio, maior será a aderência das técnicas propostas por Domain-driven Design. Se o software que…" Ler mais »

Não seria “Quanto” ao invés de “Quando” no início do parágrafo?

Rodrigo
Rodrigo
2 anos atrás

Após procurar por vários meses “cursos” sobre DDD que não me ensina-se apenas código, tinha deixado o estudo do DDD de lado… más com seus vídeos estou conseguindo aprender a essência e mais que isso aprender o porque e quando utilizar …. Obrigado

Giovanna Moreira
Giovanna Moreira
2 anos atrás
Feedback no conteúdo deste capítulo Meu primeiro contato com Domain-driven Design aconteceu em 2006. Encontrei a primeira edição do livro azul, escrito por Eric Evans,…" Ler mais »

Sou estagiária de TI, e a pedido do líder da minha equipe, estou estudando DDD para ingressar no meu primeiro projeto. É incrível logo de cara já ter contato com DDD, mesmo que ainda de forma bem iniciante. Estou achando fantástico e acredito que será muito importante para mim já começar construir meu caminho profissional com essa visão.

Sérgio
Sérgio
2 anos atrás

Assisti todo os vídeos e iniciando a leitura desse conteúdo incrível… com certeza, mais disruptivo sairei… vlw Elemar e equipe Eximia.Co

AUTOR

Elemar Júnior

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia. 

COAUTOR

Douglas Picolotto

Consultor estratégico na EximiaCo, engenheiro de nuvem, arquiteto de software e especialista em AWS e Devops.

COAUTOR

Fernando Paiva

Larga experiência como CTO, especialista em execução tecnológica e estruturação de times ágeis de desenvolvimento de software.

Seminário on-line

DDD do Jeito Certo

8 horas intensivas onde você vai aprender a atacar a complexidade no coração do software, sem aumentar a dificuldade na hora de desenvolver.

ElemarJúnior

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

TECH

&

BIZ

-   Insights e provocações sobre tecnologia e negócios   -   

55 51 9 9942 0609  |  me@elemarjr.com

55 51 3049-7890  |  contato@eximia.co

51 3049-7890  |  contato@eximia.co

4
0
Quero saber a sua opinião, deixe seu comentáriox
()
x