Domain-Driven Design de forma estratégica: O Início
O Domain-Driven Design (DDD) é uma abordagem de modelagem de domínios de negócio que atrai minha atenção desde 2015. Desde então, tenho me aprofundado cada vez mais nos estudos e na prática dessa metodologia, aprimorando minhas habilidades em grandes empresas. Ao longo da minha carreira em grandes empresas, tive a oportunidade de aplicar os princípios do DDD em diversos projetos, aprofundando meu conhecimento e aprimorando minhas habilidades.
A experiência em diferentes empresas com diferentes expectativas de negócio, molda a maneira como se olha para um projeto de tecnologia, onde antes o ponto principal e mais interessante, era conhecer a stack de tecnologia que estava sendo usada e quais eram os projetos de código existentes na empresa. Confesso que essa é a parte que também aquece o meu coração, como developer.
Com o tempo, percebi que a tecnologia, embora fascinante para uma pessoa técnica, é apenas uma ferramenta que viabiliza o sucesso do negócio. No fim das contas, o que realmente importa é o domínio do negócio da empresa. Ou seja, não importan o quão inovadora é a tecnologia, linguagem de programação, cloud provider escolhido, se essas peças técnicas não estão sendo utilizadas para atingir o objetivo do negócio. Por outro lado, se a estrutura da organização da empresa também não estiver sob uma estrutura minimamente organizada, com áreas de atuação bem definidas e sua comunicação não estiver fluindo de forma clara, objetiva e, contextualizada, a tecnologia não vai ajudar nesse sentido.
É aqui onde Domain-Driven Design entra em cena junto com a Lei de Conway.
Primeiro! Entenda o seu domínio 🔍
Durante a minha caminhada profissional, percebo que a aplicação do Domain-Driven Design em projetos, tem se dado muito mais sob a forma tática do que utilizar ferramentas que deem suporte às técnicas de modelagem estratégica. Se você se desafiar a ir ao Github e procurar por DDD ou Domain-Driven Design, vão ser listados vários projetos que usam, basicamente, artefatos táticos: Entidades, Agregados, Objetos de Valor, e que em sua maioria não contextualiza qual o dominio do problema está sendo trabalhado e quais foram as técnicas aplicadas para se chegar àquela estrutura de código. E isso é o que contribui para a geração dos famosos: Projetos DDD. Usar as técnicas táticas não está errado, mas nomear um projeto como usando DDD, apenas por isso, é o que NUNCA deveria ter acontecido na história.
Domain-Driven Design é uma abordagem de modelagem de negócio, o qual tem como fundamento compreender a contextualização de cada área de negócio, suas responsabilidades e objetivos. Cada uma dessas áreas podem ser nomeada de forma diferente, dependendo do tamanho da empresa, algumas chamam de unidades de negócio, e empresas de larga escala, essas mesmas unidades de negócio, são denominadas: Departamentos. A questão essencial por trás desses dois tipos de classificação, é a compreensão sobre o funcionamento do negócio em cada parte da empresa.
Cada empresa trabalha sobre um nicho de negócio específico o que determina qual é o Domínio de atuação daquela empresa. (claro que existem os concorrentes, mas isso não é questão para esse post) Por exemplo:
- E-Commerce: este domínio pode incluir compras online, catálogo de produtos, processamento de pedidos, pagamentos e muitas outras partes.
- Tributação: neste domínio podemos encontrar áreas como imposto sobre o rendimento, imposto sobre as sociedades, cumprimento fiscal ou política fiscal
- Assistência Médica: Aqui pode incluir áreas como gerenciamento de pacientes, agendamento de consultas, registros médicos, gerenciamento de prescrições, etc.
- Logística: Nesse tipo de domínio pode existir armazenamento, transporte, gerenciamento de estoque, otimização de rotas ou programação de entrega
Como você pode perceber, a modelagem do negócio está essencialmente ligada ao setor que você está atuando neste momento. Freqüentemente, as empresas que operam no mesmo setor são semelhantes — ou seja, são representadas por modelos ou tipos de negócios básicos e padrão que representam aspectos essenciais de qualquer negócio ou indústria. Tais representações são chamadas de Arquétipos — vou detalhar mais sobre que são Arquétipos, no post abordando os subdomínios. Isso não significa, entretanto, que todas essas partes (Subdomínios) funcionem da mesma maneira.
E isso é algo que precisamos abordar em nossa análise de um domínio de negócios, sempre que construímos (ou reconstruímos) o sistema.
Lei de Conway ⚖️
Toda empresa funciona com base na comunicação entre as pessoas e seus departamentos, o que se torna um fator essencial para uma boa condução de projetos ou uma grande confusão na execução e orquestração de projetos e roadmaps.
É fato que, em arquitetura de sistemas, existe uma máxima chamada: Depende! E essa simples palavra, demanda um ponto de reflexão grande sobre a necessidade de se aplicar alguma regra geral para todas as soluções. No entanto, existe uma um direcionamento que é regido por uma lei, o qual é fácil concordar devido a sua grande importância que é a poderosa: Lei de Conway (no inglês, Conway’s Law).
Melvin Conway em 1967, criou essa idéia, que depois vem a se tornar uma Lei, a qual descreve:
”Organizações que desenham sistemas (de qualquer natureza) são obrigadas a produzir designs que são cópias das estruturas de comunicação dessas organizações”
O que a Lei de Conway quer dizer é que é obrigatório que exista uma comunicação limpa, clara e transparente, e que aconteça de forma colaborativa entre as pessoas e departamentos, de forma a assegurar a compatibilidade entre os componentes (seja técnico ou de negócio). A estrutura técnica de um sistema vai refletir as fronteiras sociais das organizações que produzem essa comunicação.
O interessante é que essa Lei foi aplicada, primariamente, no campo da arquitetura de software, entretanto Conway direcionou a aplicação da Lei amplamente dentro de uma organização.
Vamos imaginar uma situação hipotética onde você está trabalhando em um time responsável por um subdomínio de Entrega (p*s.: abstraia aqui o tipo do Domínio principal*), dentro desse subdomínio, você vai se especializar em um nicho de conhecimento de negócio muito focado em leis logísticas, regras aplicadas à entregas, tracking das entregas, integração desse subdomínio com parceiros de tracking, dentre outros tantos conhecimentos. Só que agora, o seu time recebeu uma demanda que toca na parte te pagamentos e pedidos. Com essa demanda, chega também a obrigação de ter que atuar em outros subdomínios que você não tem o mínimo conhecimento, mas que a empresa acredita que esse tipo de operação e execução de roadmap, vai ajudar as pessoas a terem um conhecimento holístico do sistema. Legal, na teoria, não é mesmo? Mas claro que isso não funciona!
É aqui que a Lei de Conway entra em cena, ajudando as empresas refinarem as comunicações, separação de responsabilidades de áreas e definir bem as fronteiras entre esses departamentos, afim de facilitar não só o desenho de uma arquitetura consistente, mas também ajudar na organização da topologia dos times. Imagine você uma pessoa da área de Marketing, agora ter que atuar no Financeiro da empresa? 🤔
Utilize ferramentas de modelagem 📝
Bem, se você chegou até aqui, já deu para perceber que Domain-Driven Design vai muito além de Entidades e Agregadores, e até chegar ao momento da implementação, é necessário levantar informações e construir conhecimento sobre o Domínio do negócio onde você está trabalhando!
Uma maneira de facilitar esse processo de descoberta e levantamento de informações sobre o negócio de uma empresa, é a utilização de ferramentas e o agendamento de workshops os quais vão ajudar a unir as pessoas certas e transformar esse momento, em um momento de descoberta transparente e colaborativa.
Na maioria dos casos, eu tenho a prática de descobrir e descrever o caso de negócios (processos) mais crítico. Aquele para o qual o sistema será construído — total ou parcialmente, às vezes partes dos processos de negócios acontecem fora do sistema — um exemplo pode ser um processo em que uma etapa da solicitação é enviada ao sistema jurídico nacional. Devemos esperar algumas semanas pela resposta antes de continuar o processo em nossa empresa.
Propor Workshops com as pessoas adequadas para estarem dentro dessa sessão, vai colaborar com o compartilhamento de conhecimento, isso porque provavelmente vão estar nessa sessão: Especialistas de negócio, pessoas de legal, desenvolvedores de sistemas legados (Ps.: tendo em vista que essas pessoas podem ser as poucas que restam na empresa e que detem o conhecimento desses tipos de sistemas), Arquitetos/Staff/Principals. Essa sessão precisa transmitir o sentimento de que as pessoas passaram a entender o que acontece de uma maneira geral no sistema (mas não serão especialistas em tudo).
Existem alguns métodos que você pode pensar em usar. Existem muitas maneiras diferentes de fazer isso:
- Event Storming
- Domain Storytelling
- User Story Mapping
Qual seria o melhor método a ser utilizado? Para isso depende do contexto do projeto e pessoas envolvidas nessa sessão.
Se o processo for novo, ou se eu obtiver a resposta de que a maioria dos participantes preferiria um workshop de post-its, o método que eu escolheria seria o Brainstorming usando Event Storming, onde todos estão envolvidos.
Caso o processo já existe ou se os participantes preferirem diagramas, eu preferiria um workshop utilizando Domain Storytelling.
Em muitos casos, é simplesmente uma questão de preferência.
Conclusão
Esse post introduziu você sobre o prisma da parte estratégica do Domain-Driven Design. Também ficou claro que até aqui não foi abordado nenhum aspecto tático, diagramas ou designs sobre subdomínios, os tipos de entidades e agregadores dentro desses universos, nem muito menos delimitamos fronteiras através de Bounded Context (contextos delimitados) ou qualquer outro tópico relacionado a arquitetura de software ou padrões arquiteturais.
Surpreso/a sobre esse tipo de abordagem? Se a resposta foi Sim! ÓTIMO! O Objetivo desse artigo foi atingido. Para darmos o próximo passo, precisamos seguir através do caminho da análise do negócio sobre a perspectiva de um determinado domínio e seus respectivos subdomínios, utilizando técnicas e ferramentas que nos dê capacidade de levantar as informações necessárias para construirmos a modelagem do negócio e da arquitetura do sistema, e isso vai dar todas as condições para desenvolver um sistema mais ajustado a realidade do negócio.
No próximo post, vamos mergulhar no universo da modelagem do negócio para um Food Delivery, onde vamos utilizar Event Storming, onde vamos destilar alguns subdomínios.
