Introdução ao DDD - Domain-Driven Design
O DDD é usado para criar soluções de software, enfatizando a compreensão profunda do domínio do problema antes de começar a escrever código. Isso é alcançado através da colaboração entre especialistas do domínio e desenvolvedores, evitando soluções rápidas e incentivando uma abordagem crítica para resolver problemas.
No DDD, os sistemas são divididos em partes menores, chamadas de contextos delimitados. Cada uma dessas partes se concentra em uma área específica do problema que está sendo resolvido pelo software. Isso ajuda a manter as diferentes partes do sistema organizadas e coesas, o que significa que cada parte tem um propósito claro e faz sentido dentro do contexto geral do software.
Além disso, o DDD promove o uso de uma linguagem comum entre todas as pessoas envolvidas no projeto, incluindo especialistas do domínio e desenvolvedores. Essa linguagem comum, chamada de linguagem ubíqua, ajuda a garantir que todos possam se comunicar de forma clara e eficaz, reduzindo mal-entendidos e melhorando a colaboração. O design orientado a domínio é fundamental no DDD, onde as classes de domínio representam os conceitos centrais do negócio.
Esses conceitos podem parecer complexos à primeira vista, mas são fundamentais para o desenvolvimento de software bem-sucedido, pois ajudam a organizar e estruturar o sistema de uma maneira que seja compreensível e sustentável ao longo do tempo.
Desafios de Projeto
No contexto do DDD, os desenvolvedores enfrentam alguns desafios comuns. Esses desafios podem variar de projeto para projeto, mas são importantes considerações para equipes que buscam implementar o DDD de forma eficaz e bem-sucedida. Alguns desses desafios são:
Falta de Clareza nos Objetivos: Às vezes, os objetivos do projeto podem não estar claramente definidos ou comunicados, o que pode levar a soluções inadequadas ou mal direcionadas.
Escopo Creep (Expansão do Escopo): A expansão contínua do escopo do projeto pode resultar em mudanças constantes nos requisitos, levando a atrasos no cronograma e aumento dos custos.
Expectativas Irrealistas: Expectativas irrealistas em relação ao tempo, recursos e funcionalidades podem criar pressão adicional sobre a equipe de desenvolvimento e levar a resultados insatisfatórios.
Recursos Limitados: Restrições de recursos, como tempo, orçamento e equipe, podem impactar a capacidade de desenvolvimento e resultar em compromissos na qualidade ou no escopo do projeto.
Falha na Comunicação: Comunicação inadequada entre as partes interessadas, incluindo especialistas do domínio, desenvolvedores e outras equipes envolvidas, pode levar a mal-entendidos e divergências na visão do projeto.
Atrasos nas Entregas: Atrasos na entrega de funcionalidades ou iterações do software podem prejudicar a confiança do cliente e impactar negativamente o sucesso do projeto.
Falta de Transparência: Falta de transparência no processo de desenvolvimento, incluindo a falta de visibilidade do progresso, dos obstáculos enfrentados e das decisões tomadas, pode levar a mal-entendidos e desconfiança por parte dos stakeholders.
Gerenciamento de Débito Técnico: Acúmulo de débito técnico, resultante de decisões de design ou implementações rápidas que comprometem a qualidade do código, pode levar a problemas de manutenção e escalabilidade no futuro.
Design Estratégico
O Design Estratégico refere-se à estruturação das partes fundamentais de um sistema de software de maneira que elas se alinhem de forma coesa e eficaz com os objetivos do negócio, aqui temos que buscar pensar no Por que vamos desenvolver esse software e também pensar no O quê?/Qual? vamos desenvolver/método será usado.
Quando pensamos no Por que, pensamos no problema que queremos resolver. Isso envolve uma análise detalhada das necessidades do negócio, dos requisitos dos usuários e das lacunas no sistema existente, se houver. Em resumo, o "Por que" nos leva a entender a razão fundamental pela qual estamos desenvolvendo o software e os problemas que estamos tentando resolver.
Por outro lado, quando pensamos no O quê?, estamos nos referindo às funcionalidades, recursos e características específicas que serão implementadas no software para endereçar os problemas identificados. Isso envolve a definição clara dos requisitos funcionais e não funcionais do sistema, como ações que o software deve executar, dados que deve manipular e comportamentos que deve exibir. Em resumo, o "O quê?" nos leva a entender as soluções específicas que serão desenvolvidas para resolver os problemas identificados.
Domínio
O Domínio é o coração do negócio, pode ser facilmente entendido como core business do negócio, ou pensando de uma forma um pouco diferente para tentar achar qual o domínio do negócio, qual a função do negócio? Por que ele existe? Tomemos como exemplo uma escola, o domínio da escola é a educação, ou seja, ela existe para poder passar conhecimento e ensinar pessoas, preparando elas para a vida adulta (explicando de um modo mais simplista).
E qual método essa escola utiliza para fazer isso acontecer? ela ensina os alunos por meio do ensino de conteúdos e desenvolvimento de habilidades.
O domínio de uma livraria é a venda de livros. Em outras palavras, o core business dessa loja é proporcionar acesso a livros e materiais de leitura aos clientes. Por que essa loja existe? Ela existe para oferecer uma ampla variedade de livros aos leitores e promover o prazer da leitura, o aprendizado e o entretenimento por meio da literatura.
E qual método essa livraria utiliza para fazer isso acontecer? ela vende livros por meio da loja física, onde os clientes podem ir até lá e comprar. Nos dias atuais, é interessante agregar a loja física a uma loja virtual também, então a livraria realiza seu objetivo vendendo livros pela Internet.
O negócio principal da Netflix é fornecer conteúdo de vídeo aos seus clientes, como filmes, séries e documentários, por meio de uma plataforma de streaming.
O negócio principal da DHL é o transporte e a entrega de mercadorias. A DHL utiliza uma variedade de meios de transporte para realizar suas entregas.
SubDomínio
O conceito de DDD envolve a divisão do Domínio de uma empresa em subdomínios, o que simplifica nossa compreensão do negócio. Isso nos permite identificar claramente quais partes do negócio são as mais cruciais para gerar valor e retorno financeiro. Em essência, um subdomínio é uma parte menor e mais específica do domínio maior da empresa.
Independentemente do porte da empresa, sempre é possível decompor seu domínio em subdomínios. Ao fazer isso, conseguimos fragmentar a complexidade do negócio em partes mais gerenciáveis e compreensíveis. Além disso, ao trabalhar com subdomínios específicos, podemos contar com especialistas que entendem profundamente os aspectos específicos de cada parte do negócio.
Tipos de SubDomínios
Existem três tipos de subdomínios:
Principal ou Básico:
Este é o coração do negócio, onde devemos concentrar nossos maiores esforços. É o que realmente faz a empresa funcionar e gera valor para o negócio. O subdomínio principal é o que diferencia a empresa de seus concorrentes e, portanto, é onde colocamos nosso maior foco e atenção.Auxiliar ou Suporte:
Este subdomínio complementa o domínio principal. Sem ele, o domínio principal não pode ser totalmente bem-sucedido. Portanto, embora seja secundário em relação ao domínio principal, é de extrema importância e pode exigir desenvolvimento interno ou terceirização, já que não há uma solução pronta para implementá-lo.Genérico:
Este tipo de subdomínio normalmente envolve soluções prontas que podem ser adquiridas, terceirizadas ou até mesmo desenvolvidas internamente; é algo comum para todos no mercado, como filha de pagamento, contratar pessoas e etc. Não é específico para o negócio principal da empresa e, na maioria dos casos, poderia ser contratado como um serviço externo, pois não traz uma vantagem competitiva direta para a empresa.
A imagem abaixo representa um fluxograma que ajuda a identificar o tipo de SubDomínio:
Domain Expert
O termo domain expert refere-se as pessoas que possuem um conhecimento especializado em uma determinada área de negócio. Os domain experts são aqueles que estão intimamente familiarizados com os processos, procedimentos e necessidades de um domínio específico, como contabilidade, recursos humanos, educação, entre outros.
Design Estratégico
Aqui entramos com a definição de estratégia e como ela é aplicada ao DDD. Basicamente, sabendo o que queremos fazer, e porque queremos fazer, nos ajuda a entender onde queremos chegar.
Domain Storytelling
O Domain-Driven Design utiliza histórias para entendermos melhor sobre o negócio, a jornada do cliente, entre outros. Por isso, temos que aprender sobre StoryTelling, que é uma técnica que utiliza narrativas ou histórias para capturar e compartilhar o conhecimento sobre como um domínio funciona.
Isso envolve a criação de uma linguagem comum entre especialistas de domínio e equipe de TI, ajudando a construir uma compreensão compartilhada do problema que está sendo resolvido e das necessidades dos usuários finais. Essas histórias ajudam a estruturar e implementar corretamente os requisitos do software, facilitando o design de soluções mais eficazes e centradas no usuário.
Podemos usar o site Egon.io para criar uma narrativa.
A linguagem Pictográfica
A linguagem pictográfica é uma forma de comunicação que utiliza imagens ou símbolos para transmitir significado. Em vez de depender exclusivamente de palavras escritas ou faladas, a linguagem pictográfica usa representações visuais para comunicar ideias, conceitos ou informações.
Essa forma de comunicação pode ser especialmente útil em contextos onde há barreiras linguísticas, para pessoas com dificuldades de leitura ou para transmitir conceitos de forma rápida e eficaz. Exemplos comuns de linguagem pictográfica incluem sinais de trânsito, pictogramas em manuais de instruções e sistemas de sinalização em ambientes públicos.
Em Domain Storytelling, utilizaremos estes símbolos para criar uma linguagem coesa.
Atores
No contexto do DDD, "atores" referem-se a elementos que interagem com o sistema ou fazem parte do ambiente em que o sistema está inserido. Esses atores podem ser tanto pessoas como outros sistemas ou componentes externos. A narrativa é escrita na perspectiva dos atores, assim criando a história que queremos aprender.
Atores são nomeados de acordo com a função. Evitamos nomes, pois este fica específico demais e não demonstra qual a função está executando tal tarefa. Alguns exemplos são: Clientes, Gerentes, Sistema de Inventários e etc.
Objetos de Trabalho
Objetos de trabalho são utilizados pelos atores. Esses podem ser registros, entidades ou transações físicas e digitais. Os atores interagem com esses elementos, construindo a sequência dos eventos. Exemplos de objetos de trabalho abrangem desde registros físicos como pedidos e cardápios, passando por elementos digitais como bilhetes e cardápios eletrônicos, até interações como e-mails de confirmação e ligações telefônicas para fazer reservas.
Atividades
As atividades consistem nas ações executadas pelos atores em relação aos objetos de trabalho. Elas são representadas por setas, cada uma identificada pela ação que está sendo realizada.
# Poderia representar cada ator usando Pictografia!
cliente ---Solicita---> informação ---ao----> atendente
É importante observar que, durante as atividades, há duas ausências propositais:
Evitamos o uso de condicionais (if-else), e isso não é coincidência. Nosso objetivo é destacar o que é crucial no desenvolvimento da narrativa. Qualquer condição será tratada como uma nova narrativa, porém, isso será abordado posteriormente.
Não incorporamos retornos (loopbacks) no mesmo fluxo. Embora seja comum em programação demonstrar retornos ao cliente ou ao servidor, nosso foco aqui é simplesmente contar uma história. Portanto, em vez disso, narramos uma história em que o intento do ator é de suma importância, em vez de sua interação direta. Essa abordagem pode ser explorada por meio de outras técnicas, como o BPMN.
Números Sequenciais
Para uma história ser verdadeiramente eficaz, é necessário não apenas um enredo convincente, mas também uma sequência lógica. No Domain Storytelling, utilizamos a Sequência Numérica para nos orientar ao longo da narrativa.
No desenvolvimento de sistemas, é comum encontrar situações que ocorrem simultaneamente. Nessas circunstâncias, ambas serão numeradas da mesma forma. No entanto, é aconselhável tomar cuidado ao fazer isso e evitar essa prática com frequência. Um aspecto crucial a considerar é que, ao criar a narrativa, é o Domain Expert quem a conduz. Podemos encontrar sequências lógicas fora de ordem, o que requer ajustes na numeração.
Anotações
Como o nome já diz, são anotações que realizamos ao documentar a história. Essas notas contêm detalhes cruciais, como restrições na atividade, passos a serem seguidos, desencadeadores para outros procedimentos ou eventos, entre outros.
Grupos
Grupos são representações de partes de uma história. Por exemplo, ações que são repetidas constantemente, subdomínios, limitações do processo etc. Grupos são representados por linhas de limite no nosso design.
Cores
Frequentemente, podemos empregar cores para enfatizar uma série de atividades, realçando assim características específicas.
Cenários
Como discutimos anteriormente, a linguagem pictográfica nos fornece uma estrutura para interpretar as informações fornecidas pelo usuário, permitindo-nos criar uma linguagem distinta que ilustra o fluxo da história, seus protagonistas, objetos e atividades. No entanto, toda boa história, além de seu enredo principal, apresenta suas próprias variações.
Escopo
Sempre que abordamos o escopo, tendemos a pensar em algo definido, ou seja, algo que tem um início, meio e fim. No entanto, isso não significa que não haja variações dentro desse processo e suas respectivas limitações.
Quanto ao alcance das histórias, de acordo com Cockburn (2001), nosso limite aceitável seria o nível do mar, ou seja, os objetivos do usuário até o nível da ostra. Por exemplo, se você já explorou uma história em profundidade, isso não significa que mais tarde você não possa ir ainda mais fundo.
Realidade vs Desejo
Quando falamos sobre ouvir e registrar a história do usuário, é importante lembrar que uma história pode ter várias versões. Nesse contexto, é crucial ouvir todos os Domain Experts, consolidar o que foi ouvido e compreender se o que estamos mapeando reflete a realidade atual, ou seja, o que ocorre no presente. Ou se o Domain Expert está compartilhando suas aspirações para o futuro.
Mapear histórias envolve o desenho de um processo para criar uma solução. Ao ouvirmos nosso Domain Expert, ele pode nos narrar uma história conforme a vivencia em seu dia a dia, refletindo a realidade do usuário. No entanto, como afirmou Heráclito de Éfeso: “Ninguém entra em um mesmo rio uma segunda vez, pois, quando isso acontece já não se é o mesmo, assim como as águas que já serão outras”. Essa citação pode ser aplicada para compreender a mente do nosso Domain Expert, pois ao descrever a história, a pessoa pode fazer uma autocrítica e começar a conceber novas maneiras de realizar tarefas ou processos.
Como resultado, temos duas narrativas: uma representando nossa realidade atual (AS IS) e outra retratando uma nova realidade ou futuro desejado (TO BE). É importante ressaltar que a solução que vamos desenvolver não surgirá instantaneamente com a nova realidade, mas pode ser algo a ser implementado no futuro, ao longo do desenvolvimento. Isso pode ser melhor abordado utilizando metodologias ágeis, por exemplo.
Domínio Puro e Digitalizado
O termo "domínio puro" refere-se ao conhecimento e compreensão do domínio de negócios em sua forma original, sem qualquer abstração ou representação digital. É o conhecimento que os especialistas têm sobre os processos, regras e conceitos que regem uma determinada área de negócio.
Resumindo, são as interações entre os Atores, sem ressaltar a tecnologia sendo utilizada.
Por outro lado, "domínio digitalizado" envolve a tradução desse conhecimento do domínio de negócios para representações digitais, como modelos de dados, diagramas, código de software, entre outros artefatos digitais. É o processo de capturar, modelar e implementar o conhecimento do domínio em sistemas de software.
Resumindo, são as interações entre os Atores, e as tecnologias que estão sendo utilizadas.
Equipe de Trabalho
Agora que mapeamos a história, avançamos para a próxima etapa: a implementação. Como desenvolvedores, não temos conhecimento completo do domínio, ou seja, da história, então é crucial formar uma equipe que nos auxilie nessa tarefa. O passo mais crucial agora é selecionar as pessoas certas para compor a equipe, indivíduos que possuem conhecimento do domínio e que contribuirão para a história.
Uma sugestão de composição da equipe é a seguinte:
- Domain Experts: Quantos forem necessários para relatar a história com detalhes.
- Ouvintes: Todos aqueles interessados em aprender sobre a história, normalmente incluindo a equipe de desenvolvimento e outros membros relevantes.
- Moderador: Responsável por conduzir as conversas, elaborar perguntas relevantes e manter o foco no objetivo pretendido.
- Modelador: Encarregado de transformar a história em linguagem pictográfica e realizar as devidas anotações para registro e compreensão.
Abaixo segue um exemplo prático de como criar um StoryTelling fornecido pela FIAP.
Fontes
https://schoolofprogrammer.com/pt/ddd-dominios-e-subdominios/