DDD raiz! Como ter resultados com Domain Driven Design (DDD) na prática!

Introdução

O DDD está em alta em todas empresas grandes e complexas, principalmente as que estão na jornada de transformação digital. Mas de fato, como sair da teoria dos livros (Eric Evans e Vaughn Vernon)?

Bom, nesse artigo irei compartilhar um pouco da jornada que tivemos em uma das maiores empresas de varejo da latam.

Ao me deparar com o desafio de estar como líder técnico de uma tribo o primeiro ponto que tive, foi o reconhecimento do ambiente e de fato foi bem desafiador, por ser uma empresa em transformação digital, existia um cenário muito conflitante em relação aos papeis, responsabilidades, execução de atividades (estratégico, tático e operacional), direcionamento estratégico do C-Level, contexto de negócio e por fim, não menos importante, estruturação do time e etc.
Nesse contexto, a solução macro para o domínio principal de negócio é feito através de um software de mercado, SaaS. Um dos melhores do quadrante mágico para o assunto.

Mas e aí, como inovar, desacoplar e transformar algo em um cenário como esse?

Nesse ponto percebi que era uma grande jornada a ser percorrida e precisaria de aliados para cumprir as missões e de fato agregar valor à companhia.

Por estarmos em um contexto de SaaS, incialmente o foco foi em organizar a casa e rodar o melhor possível das metodologias (Kanban e Safe), sem esquecer, obviamente, de manter o avião voando.

Depois disso, tivemos 2 grandes iniciativas:

1 — Criação de ambiente tecnológico para inovação, desacoplamento e modernização (Aqui usando as teorias do Philip Kotler no livro Marketing 5.0 — quando ele fala do preparo digital da empresa (1 — experiencia digital do cliente; 2 — infraestrutura digital; 3 — organização digital) o foco foi na infraestrutura);
2 — Domain Driven Design (DDD) — Houve muita resistência para iniciar os desenhos, primeiro por desconhecimento e segundo por "não necessidade", a "não necessidade" se deu por conta do domínio principal ser suprido por um SaaS.

Para o item 1, vou criar um outro artigo para falar no detalhe cada ponto, resumidamente, foi um assunto, por incrível que pareça, mais complexo que de fato o DDD e codificar os microserviços.

Para o item 2, que é o foco desse artigo, entraremos no detalhe. Lembra quando falei ali acima que precisaria de aliados para o desafio?

Criei conexões com os líderes de produtos e consegui "vender" o real valor do desacoplamento. Além disso, trouxemos um profissional especialista em DDD para colocar na prática a estratégia definida. Ao direcionar para aplicar o DDD ao nosso contexto de negócio, ele conseguiu conduzir o trabalho de desacoplamento na prática.

Na prática

1-Entrevista com usuários

Para fazer essa dinâmica, foi iniciado entrevistas com os donos dos produtos e os especialistas técnicos para entendimento dos fluxos de maneira fluída. Isso serviu para definir os nomes dos domínios, bounded context, entidades e linguagem ubíqua. Isso foi feito no excel mesmo e demorou aproximadamente 2 meses.

Figura 1 — Entrevista com usuário para definição dos domínios e entidades (posteriormente criar o Blueprint)

2-Glossário (aplicação da linguagem ubíqua)

Depois da definição dos fluxos, ou em conjunto, foi feito um glossário dos termos usados pelo negócio e pela empresa. Aqui é o mapeamento do AS IS, como as pessoas (tanto de negócios quanto técnicos) falam determinados termos e o que eles significam pensando no fluxo/domínio. Esse trabalho é bem complexo por conta dos vícios e abreviações empregados no dia-a-dia.

Figura 2 — Glossário de termos

3-Blueprint técnico funcional recursos (AS IS)

Agora que já temos os fluxos e o significado dos termos, conseguimos definir o blueprint AS IS do domínio. Essa parte foi relativamente mais tranquila em relação aos passos anteriores, foi "só" consolidar o trabalho feito nos passos 1 e 2.

Figura 3 — Desenho do Blueprint técnico separado por sub-dominios e composto pelas entidades.

4-Blueprint técnico funcional Interfaces (AS IS)

Essa fase é importante para saber as conexões existentes no domínio. Quanto mais interfaces, mais complexo vai ser o desacoplamento do domínio.

Figura 4 — Desenho das interfaces detalhando as conexões e responsabilidades.

5-Mapeamento de domínios

Aqui vamos mapear os Domínios e os contexto e o fluxo macro (até a fonte do dado). Esse desenho é importante para saber o que tange o contexto inserido e o quanto contido está a entidade.

Figura 5 — Mapa de domínios e seus relacionamentos

6-Mapa de contextos

Nesse passo volta a treta (discussão sadia), do que é core (domínio principal) ou não. As pessoas que não conhecem ou nunca aplicaram o DDD têm dificuldades em delimitar o domínio core e o não core em questão.

Figura 3 — Mapa de contextos

7-Definição de complexidade

Infelizmente não posso detalhar todo o contexto, mas o objetivo desse passo é você identificar qual recurso tem menor impacto para o seu negócio, recomendo fortemente em começar o desacoplamento para o domínio de menor impacto e com menor interação.

8-Desenho da arquitetura de solução da Entidade a ser desacoplada

Depois de ter escolhido a entidade a ser desacoplada é a hora de desenhar a arquitetura de solução. No caso vamos usar o padrão C4 para desenho das peças técnicas e suas interações.

Por questões de compliance irei colocar um desenho C4 genérico para ilustrar o trabalho feito. Lembrando que o objetivo do artigo é compartilhar o passo-a-passo na prática de como de fato desacoplar um serviço e não passar pelos detalhes de arquitetura e engenharia de software! (Quem sabe em uma v2 detalhemos melhor… só depende de vocês, se o conteúdo estiver fazendo sentido :D )

Conclusão

Bom, à partir daqui o upstream técnico já foi feito. Agora é enviar para o downstream, priorizar com o GPM e delegar ao DevTeam para desenvolver a solução.
O último ponto para compartilhar sobre esse assunto é em relação à dificuldade de rodar iniciativas desse tipo. Caso a área de negócios ou produtos não seja promotora desse tipo de iniciativa, traga dados!!! Contra dados não há argumentos, não é mesmo? rs
Alguns dados que possam te auxiliar a vender:

• Métricas de negócio
  - Leadtime (Tempo gasto para desenvolver uma solução antes e a projeção para depois do desacoplamento)
• Métricas tech (Livro Accelerate)
  - MTTR
  - Time to first deploy
  - Todas camadas de observability
  - Deploy A/B
  - Tempo para Rollback
• Métricas financeiras
  - ROI (Avaliar custos do legado do AS IS x Custos do TO BE)

Espero que de alguma forma essa experiência e essa jornada tenha servido para você. O Grande objetivo foi passar pelos passos na prática de como sair da teoria até a prática e entregar valor real à Companhia.

Gostaria de agradecer a todos que fizeram parte e contribuíram para esse trabalho. Walter Rodrigues, Luiz Queiroz, Gustavo Guandalini e Ronaldo Barbara. O Luiz liderou com maestria a elaboração do trabalho e o Gustavo atuou de forma excelente como TechLead e Domain Expert.