Arquitetando o Produto: Separando em Partes (c/ DDD)
Tenho certeza de que o caro leitor já ouviu a seguinte expressão: “Dividir para conquistar”. Essa frase já foi usada em diferentes contextos e momentos ao longo da história. Sua primeira aparição foi atribuída a Nicolau Maquiavel, em seu livro a “A Arte da Guerra” (não confundir com A Arte da Guerra de Sun Tsu que citei no artigo anterior). Julio César, Napoleão e Thomas Jefferson também já utilizaram, todos os exemplos até aqui citados foram no contexto de estratégia militar.
Já em 1980 Seymour Papert também usou essa expressão, porém dentro do contexto “pensamento computacional”, que era tema em suas pesquisas pioneiras sobre o uso de computadores como ferramentas de aprendizagem, principalmente para a resolução de problemas. Uma das etapas dessa abordagem era a Decomposição, que consistia em fragmentar o problema em partes menores e, consequentemente, mais fáceis de serem analisadas e compreendidas. Ele fez uma clara referência ao “Algoritmo Dividir para Conquistar” usado na Ciência da Computação para resolver problemas.
O objetivo desse artigo é apresentar ao leitor uma forma de separar um produto em partes, ou então, separar um problema em outros pequenos problemas para facilitar a solução. Sabemos que construir produtos digitais é difícil. Para ter sucesso, temos que aprender continuamente, seja experimentando novas linguagens, explorando novas tecnologias ou acompanhando novos frameworks populares. No entanto, aprender uma nova biblioteca JavaScript toda semana não é o aspecto mais difícil do nosso trabalho. Entender novos domínios de negócios pode ser muito mais desafiador e vou tentar explicar o porquê.
Para quem vem de uma carreira técnica na área de desenvolvimento de software, percebeu ao longo da sua carreira que não é incomum termos que desenvolver softwares para diversos domínios de negócios: sistemas financeiros, sistemas fiscais, sistemas logísticos, sistemas de estoque, sistemas de aprendizagem e muitos outros. De certa forma, é isso que diferencia nosso trabalho da maioria das outras profissões. As pessoas que trabalham em outras áreas geralmente ficam surpresas quando descobrem quanto aprendizado está envolvido na engenharia de software, especialmente ao mudar de local de trabalho. É muito mais frenético e rápido do que qualquer outra profissão fora do mundo tech que me venha em mente.
Sabendo disso, vamos ver nesse artigo uma ferramenta que se propõe a atacar a causa raiz de boa parte das falhas na construção de um produto, porém de um ângulo diferente. O design orientado por domínio (DDD), sim ele mesmo, colocando a comunicação eficaz como tema central das ferramentas e práticas de design orientadas por domínio. Veremos que, se bem utilizado pode ser a principal ferramenta para alinhar a Arquitetura de Software com as Estratégias do Negócio. Se você é desenvolvedor de software, conhece DDD e não viu valor ou não entendeu como ele pode ajudar a resolver esse tipo de problema, talvez você só tenha focado o aprendizado na parte técnica do DDD. Não fique surpreso, isso acontece muito.
Domain-Driven Design (DDD)
O DDD consiste em duas disciplinas relacionadas: Design Estratégico e Design Tático. Em essência, o Design Estratégico é sobre determinar o que precisamos construir (“what?”, “why?”). Design Tático é sobre como o construímos (“how”). Ambos os padrões e práticas estratégicas e táticas de DDD alinham o design de software com seu domínio de negócios. É daí que vem o nome: (business) domain-driven (software) design.
Design Estratégico
Relaciona-se com a especificidade do negócio (domínio) e com a estratégia para resolver o seu problema: compreender os problemas que uma empresa deve resolver; onde alcança vantagens competitivas; as relações entre as equipes; e com tudo isso em mente, que produto construir.
Espaço do Problema
O espaço do problema é onde residem as necessidades de seus clientes. É o momento que você aprende mais sobre os usuários e seus problemas para permitir que se determine o que seu produto precisa fazer. Essencialmente, é a base sobre a qual o espaço de solução, que vou falar adiante, se sustenta.
No entanto, aprender sobre as necessidades dos clientes não é a tarefa mais simples. É provável que nem sempre você aprenda quais são essas necessidades facilmente. O processo requer paciência e tempo, mas principalmente o envolvimento de especialistas do domínio (aqui a maior negligência). Para ser eficaz, você precisa de habilidades que possam permitir que se conquiste a confiança dos clientes e sua cooperação.
A aparente dificuldade envolvida nesse espaço pode fazer com que as equipes de Gestores de Produtos e Arquitetos queiram gastar menos tempo nele. Identificar as áreas problemáticas em um domínio é chamado de Análise do Espaço do Problema. Isso requer uma estreita colaboração com os Especialistas em Domínio, as pessoas que melhor conhecem o negócio.
Um domínio define a principal área de atividade de uma empresa. De um modo geral, é o principal serviço que a empresa presta aos seus clientes. Por exemplo:
- O iFood fornece entrega de alimentos.
- A Starbucks é mais conhecida por seu café.
Uma empresa pode operar em vários domínios de negócios. Por exemplo, a Amazon fornece serviços de varejo e computação em nuvem. A Uber é uma empresa de compartilhamento de viagens que também fornecia (nunca mais vi) serviços de entrega de comida e compartilhamento de bicicletas.
Para atingir os objetivos e metas de seu domínio de negócios, uma empresa precisa operar em vários subdomínios. Todos os subdomínios de uma empresa formam o seu domínio de negócio: o serviço que presta aos seus clientes. A implementação de um único subdomínio não é suficiente para o sucesso de uma empresa é apenas uma das partes no sistema (é daqui que nasce a separação). Por exemplo, o iFood pode ser mais reconhecido por serviço de entrega, mas construir uma rede de entregas de sucesso requer mais que isso. Você também precisa cadastrar estabelecimentos, gerenciar cardápios, realizar pedidos, fazer promoções. Nenhum desses subdomínios por si só fará uma empresa lucrativa. Todos eles juntos são necessários para que uma empresa seja capaz de competir em seu(s) domínio(s) de negócios.
Espaço da Solução
O espaço da solução é onde vivem os produtos e as representações de produtos que são direcionados ao cliente, eles representam a resolução do problema.
As pessoas geralmente são encorajadas a serem solucionadoras de problemas, para fornecer soluções. Portanto, não é de surpreender que as equipes de desenvolvimento e produtos sejam atraídas mais pela solução na construção de produtos. E pode não importar se o tempo suficiente foi gasto entendendo o problema para criar bons requisitos. Bons profissionais costumam não perder os problemas de vista, parece simples, mas não é.
Importante não confundir com aquela frase mal-acabada repetida N vezes em treinamentos de liderança: “Não me traga problemas, me traga soluções!”. Solucionar o problema errado é pior do que não fazer nada, acredite.
Definido o espaço do problema com domínios e subdomínios, é hora de trabalhar no espaço da solução. No espaço da solução nós temos duas equivalências para domínios e subdomínios que são modelos de domínio e contexto delimitado.
Começando pelo modelo, é uma representação simplificada de uma coisa ou fenômeno que intencionalmente enfatiza certos aspectos enquanto ignora outros. É uma abstração com um uso específico em mente. Um modelo não é uma cópia do mundo real, mas uma construção humana que nos ajuda a entender os sistemas do mundo real.
Um exemplo convencional de um modelo é um mapa. Qualquer mapa é um modelo, incluindo mapas de navegação, mapas de terreno, mapas de rodovias, mapas de metrô e outros. Nenhum desses mapas citados representa todos os detalhes do nosso planeta. Em vez disso, cada mapa contém apenas dados suficientes para apoiar seu propósito específico: o problema que deve resolver.
Já contextos delimitados definem uma linguagem ou modelo comum dentro de um subdomínio. Normalmente, quando a linguagem ou modelo começa a mudar de significado, isso significa que outro contexto delimitado pode ser criado.
Como escrevi acima, um modelo não é uma cópia do mundo real, mas uma construção que nos ajuda a entender um sistema complexo. O problema que deve resolver é uma parte inerente de um modelo, seu propósito. Um modelo não pode existir sem um limite, ele se expandirá para se tornar uma cópia do mundo real. Isso torna a definição do limite de um modelo, seus contextos delimitados, uma parte intrínseca do processo de modelagem.
Vamos novamente ao exemplo dos mapas como modelos. Vimos que cada mapa tem seu contexto específico — navegação, terreno, metroviário e assim por diante. Um mapa é útil e consistente apenas dentro do escopo de seu propósito específico. Portanto, um mapa do metrô é inútil para a navegação náutica e é assim que definimos a aplicabilidade de um contexto delimitado.
Design Tático
Esse tipo de design refere-se a padrões, ferramentas e práticas que simplificam a criação de Modelos de Domínio úteis. Usamos o Design Tático quando temos uma lógica de negócios complexa para modelar ou quando a complexidade pode ser introduzida no futuro.
As ferramentas táticas do design orientado por domínio abordam um aspecto diferente dos problemas de comunicação. Os padrões táticos do DDD nos permitem escrever código de uma forma que reflita o domínio do negócio, aborde seus objetivos e fale a linguagem do negócio.
Notadamente, este artigo não irá focar nessa parte do DDD, por entender que é a parte em que a maioria dos artigos disponíveis sobre o tema já abordam com certa frequência.
Linguagem Ubíqua
Dentro do Design Estratégico e Tático existe um pressuposto que é a ideia de Linguagem Ubíqua. Este é um conjunto inequívoco e bem definido de termos que refletem a linguagem usada em um contexto de negócios. O uso consistente da Linguagem Ubíqua em conversas, requisitos e código, remove a sobrecarga e os erros associados à tradução regular de conversas técnicas para conversas de negócio.
Alinhar este espaço de solução com a realidade do seu espaço de problema é o foco principal do DDD.
O DDD adota uma abordagem holística da complexidade, alinhando especialistas em domínio no espaço do problema e engenheiros que implementarão o espaço da solução. Ter uma linguagem ubíqua entre o problema e o espaço de solução também é uma característica definidora do DDD. Por exemplo, em ferramentas acessórias como Event Storming e Domain Storytelling, para explorar melhor os problemas dos subdomínios é fundamental usar a linguagem ubíqua.
Um livro inteiro poderia ser dedicado a este assunto, por isso sugiro fazer mais algumas pesquisas sobre este importante tópico! O Foco desse artigo não é ser um guia ou uma explicação completa de DDD. Se sentir falta disso, recomendo a leitura dos dois livros abaixo e assistir a série DDD do Jeito Certo do meu amigo Elemar Jr. Aliás, recomendo seu curso online sobre o assunto.
Associando DDD com Wardley Maps
No artigo anterior (Arquitetando o Produto — Guiado pela Estratégia), escrevi sobre Wardley Maps, um modelo que ajuda a projetar e desenvolver estratégias de negócios com base na consciência situacional e no movimento natural do panorama, seguindo um ciclo estratégico. Se você não leu, recomendo que vá até ele e complete a leitura, fará mais sentido.
Bom, nesta perspectiva, podemos aliar o design orientado por domínio, ao nosso mapa estratégico criado anteriormente. Para construir um software melhor, temos que alinhar seu design de software com o domínio de negócios, com as necessidades de negócios e a estratégia de negócios. E o DDD também nos ajuda a aplicar os princípios doutrinários do Wardley Map. Talvez as ferramentas de Design Estratégico do DDD sozinhas não são suficientes para uma boa representação entre todos os envolvidos, por isso a associação com Wardley Map pode ser um grande diferencial.
Como dito anteriormente, ao analisar e explorar o domínio do problema, particionando o domínio do problema em subdomínios menores, percebemos que nem todos os subdomínios são iguais, alguns deles são mais valiosos para os negócios do que outros. Portanto, temos diferentes tipos ou diferentes categorias de subdomínio, como subdomínios principais (Core), de suporte (Supporting) e genéricos (Generic).
O subdomínio principal (core), que é a parte essencial do domínio do problema que fornece vantagem competitiva, são as partes do sistema que o tornam um sucesso e deve ser difícil para os concorrentes copiar ou imitar e, geralmente são bastante complexos, eles tendem a mudar com maior frequência.
O subdomínio de suporte (supporting) ajuda a suportar o domínio principal e não fornece nenhuma vantagem competitiva. Eles costumam ser bastante simples, não mudam com frequência e, se possível, devemos procurar comprar produtos de prateleira ou usar software de código aberto que vá para produção o mais rápido possível. Se isso não for possível e se tivermos que customizar o suporte no subdomínio, não devemos investir muito nessa parte do sistema porque não é vista como valor. Podemos até considerar uma terceirização dessa parte.
Os subdomínios genéricos (generic) são subdomínios comuns na maioria dos sistemas, por exemplo, autenticação ou gateways de pagamentos etc. Portanto, apesar de serem necessários não oferecem vantagem competitiva. As empresas não podem funcionar sem eles e como geralmente são complexos, mas já resolvidos por outras empresas, temos que entender que componentes relacionados ao subdomínio genérico devem se possível ser comprados ou usar algo pronto. Esses produtos são bem conhecidos e divulgados por empresas especializadas como fornecedores de commodities. Dificilmente há necessidade de inovação aqui para o subdomínio genérico.
Poxa, mas até aqui só vi os subdomínios do DDD e nenhuma relação com Wardley Maps. — Leitor
Então, talvez não esteja tão nítido, e quem observou muito bem essa relação foi Susanne Kaiser. Desde então sempre que vejo um sistema sendo decomposto ja começo a pensar nessas diferentes categorias de subdomínio principais, de suporte e genéricas e como elas nos ajudam a mapear o nosso produto dentro dos padrões climáticos do Wardley Map e com isso vamos entendendo melhor todo o panorama.
A correta classificação e distribuição dos subdomínios podem nos ajudar a priorizar o esforço de desenvolvimento, porque o maior esforço de desenvolvimento deve ser canalizado para os subdomínios principais, onde são componentes/serviços que tem relação com o que temos que investir estrategicamente. É onde nosso maior esforço de desenvolvimento deve ser direcionado. É onde devemos deter o maior conhecimento.
O subdomínio principal do nosso sistema são os subdomínios do nosso sistema que precisamos construir dentro de casa e eles devem entrar em Genesis e no estágio Custom Built.
O processo de descoberta dos subdomínios e o seu correto enquadramento em um Wardley Map pode ser uma ótima ferramenta de comunicação. Perceba que um mapa tem esse poder de representação visual, portanto, explicar e realizar esse exercício com todos os stakeholders deverá trazer clareza da estratégia de construção do produto.
Uma vez que no espaço do problema já não há mais dúvidas sobre os subdomínios é hora de partir para o espaço da solução. Nela teremos oportunidade de mapear os Contextos Delimitados do Design Estratégico e posteriormente partir para o Design Tático aplicando Padrões de Arquitetura e outras ferramentas táticas do DDD. Vejamos um exemplo abaixo.
Se você caro leitor ja transitou na área técnica, seja como Arquiteto ou seja com Desenvolvedor Senior, já deve ter lido ou ouvido falar que DDD não deve ser aplicado “de cabo a rabo” em um produto. Essa afirmação é verdadeira, porém muito mais verdadeira se olharmos do ponto de vista do Design Tático. Perceba na imagem acima que a descoberta de Subdomínios e a associação aos Contexto Delimitado pode ocorrer em todo o sistema. Aí sim, a partir disso e com o devido enquadramento no mapa é possível definir se o domínio é composto de múltiplas partes e que partes poderiam usar as ferramentas táticas do DDD. Na prática é muito comum a aplicação das ferramentas táticas do DDD em todo o produto, mas elas são realmente indicadas para a maioria dos subdomínios principais (core) e alguns subdomínios de suporte (supporting).
Um contexto delimitado também pode servir como um limite físico e pode ser implementado como soluções separadas (Microservices). E nem todos os contextos delimitados compartilham os mesmos padrões de implementação de lógica de negócios ou arquitetura. Em vez disso, eles podem diferir para cada contexto delimitado. Portanto, derivar modelos de domínio e seu contexto delimitado relacionado não é uma tarefa trivial e não há problema em não acertar de primeira. Esse processo é muito incremental enquanto se ganha conhecimento de domínio durante a colaboração entre os especialistas de domínio e as equipes de desenvolvimento.
Abordar a questão de qual é o foco principal enquanto satisfazemos as necessidades do usuário, deve iniciar nas conversas entre os especialistas de domínio e as equipes de desenvolvimento. Existem diferentes técnicas disponíveis para derivar modelos de domínio e contextos delimitados como as já citadas EventStorming, Domain Storytelling, Mapping User Stories e assim por diante. O ponto é que associar DDD com Wardley Map, como no exemplo acima, traz uma maior clareza sobre o panorama do Produto, como ele está sendo concebido e qual a devida importância de cada uma das partes mostrando claramente onde precisamos colocar os maiores esforços.
Concluindo
Descobrir o domínio principal e entender qual é vantagem competitiva, permite que nos concentremos no que realmente importa, nos trazendo uma consciência altamente situacional para que seja fácil comunicar nosso cenário e como estamos operando competindo.
Isso nos permite entender e comunicar de forma clara para toda a equipe onde estamos e em comparação com nossos concorrentes. Decompor nosso sistema em componentes modulares e o contexto delimitado que nos permite particionar nosso produto em partes menores, de acordo com o panorama de momento. Com o contexto delimitado como uma forma específica e autônoma de uma parte do domínio, deixando este em conformidade com os princípios doutrinários apresentados em Wardley Map.
As categorias dos subdomínios mapeados no DDD para seus estágios de evolução do Wardley Map revelam onde investir estrategicamente a maior parte do esforço de desenvolvimento, onde faz mais sentido comprar produtos prontos ou usar software de código aberto e onde terceirizar para fornecedores de serviços públicos, deixando claro que existem métodos apropriados para cada estágio de evolução.
No próximo artigo (Arquitetando o Produto: Organizando os Times) pretendo escrever sobre como a separação em partes do produto pode ajudar na organização dos times que resolvem os problemas e necessidades do cliente.
E aí, já tinha visto a associação de DDD com Wardley Maps para apoiar o plano estratégico do produto? Gostou desse modelo e da forma como ele foi concebido? Deixe a sua opinião 😃👍
Estou compartilhando algumas ideias nos seguintes artigos:
Arquitetando o Produto: Guiado pela Estratégia;
Arquitetando o Produto: Organizando os Times;
Arquitetando o Produto: Juntando as Peças;
Espero que tenham gostado e até lá!!! 😃
