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, entretando 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.
Top comments (0)