O Domain driven design é uma técnica que ajuda a organizar a construir um software de modo a agregar o máximo de valor possível. Trata-se de uma abordagem que usa como premissa o entendimento específico da complexidade do software e a partir dele gerar as estruturas adequadas.

Essa abordagem, que para alguns é um design e para outros uma arquitetura, foi elaborada por Erik Evans em seu famoso livro. (‘Domain Driven Design: Atacando as complexidades no Coração do Software’, escrito em abril de 2003). Esse artigo tenta apresentar uma forma de pensar a empresa pelo uso de frameworks corporativos. Tais como Balanced Scorecard ou BSC, Objectives and Key-Results ou OKR, muito focado na estratégia. E a partir desse ponto ele desenrola até chegar ao Domain Driven Design estratégico.

Se seu objetivo é querer entender elementos como repository, agregações, value-objects ou mesmo estruturas de pastas comumente utilizadas em projetos desse tipo, entenda que esse artigo não entregará tais características. Pelo contrário, ele entregará os passos anteriores que fundamentam o uso do DDD numa empresa. Uma vez que entendo que esses elementos sem a estratégia não são DDD, mas tão somente nomes de pastas ou classes. De todo modo escreverei em algum momento um artigo sobre eles.

Estratégia corporativa

Estratégia corporativa e a relação com o software

A primeira coisa que gostaria de fazer é demonstrar que o DDD não é apenas uma ferramenta ligada a tecnologia. Mas ao contrário, ela é diretamente ligada ao negócio e aos objetivos da organização. Quando bem estruturados esses objetivos são potencializados com a correta implementação do Domain Driven Design.

Vale ressaltar que a estratégia da organização norteia tanto a estrutura corporativa (negócios existentes, modelos de negócio, fluxo de caixa, margens, etc.) quanto a própria estrutura do software, uma vez que ela tende a refletir tais características.

Começo então comentando sobre o Balanced Scorecard (BSC) e sobre o Objectives and Key Results (OKR) estabelecendo a estratégia corporativa como base para a boa implantação do DDD na organização. Destaco também que esses modelos podem ser utilizados isoladamente ou em conjunto, ou outros modelos também podem ser utilizados. Mas esses são, sem dúvida, referências amplamenta utilizadas.

Balanced Scorecard, BSC

O Balanced Scorecard ou BSC é uma ferramenta de apoio a estratégia criada por Robert Kaplan e David Norton no início da década de 90. Ele é um sistema que estrutura medidas de forma organizada para que a visão da empresa (ou de uma área, ou qualquer outro tipo de organização) seja alcançada. Ele possui um equilibrio entre as questões financeiras e não financeiras evitando o risco de visões viciadas focadas em apenas um desses aspectos: algo muito comum em organizações sem estratégia bem definida.

Assim, o BSC é orientado a visão estabelecida para a organização. A visão é uma declaração clara e concisa do compromisso da empresa com o que ela quer ser no futuro. E ela é a base para todas as decisões estratégicas da empresa ajudando a alinhar todos os esforços e ações em torno de um objetivo comum.

Perspectivas do Balanced Scorecard

Considerando a visão como raiz da estratégia da organização o BSC estabelece quarto perspectivas para que ela seja alcançada: e como comentei, algumas são financeiras e outras não. Mas a primeira é financeira, uma vez que o atingimento dos objetivos sempre necessita de recursos desse tipo, mesmo para organizações do terceiro setor como ongs e afins. As demais parspectivas são derivações da financeira que propiciam que ela seja alcançada.

A perspectiva de clientes ou mercado observa as questões associadas ao mercado, aos clientes e a relação necessária para que a perspectiva financeira seja alcançada. Mas note que as perspectivas são livre, umas das outras, de modo que elas pode ser observadas apenas por elas mesmas, caso a organização da empresa suporte essa forma.

Seguindo há a perspectiva dos processos internos. Se nas perspectivas financeira e clientes há um olhar para fora da organização, essa perspectiva e a próxima (que ainda vou comentar) foca seus esforços na estrutura interna e o que pode ser diretamente feito para que tais objetivos sejam alcançados. Essa perspectiva, como o nome diz, tem o foco em como melhorar os processos para que a perspectiva dos clientes seja melhor alcançada.

Por fim há uma perspectiva ligada diretamente aos conhecimentos necessários para que todo o modelo seja possível. De modo geral, alcançar os objetivos exige habilidades e conhecimentos que ainda não existem na empresa e essa perspectiva tem esse foco.

Síntese

Notem que as perspectivas se conectam numa cadeia através de seus objetivos. Uma perspectiva deve ter alguns objetivos: eu recomendaria que não passe de seis. Cada uma das perspectivas deve ter metas que indicam o que precisa ser feito para considerá-la como cumprida; indicadores, que apoiem as metas; e iniciativas ou projetos, que são ações práticas que movimentam os indicadores no sentido da meta.

Veja a seguir um diagrama exemplificando de maneira abstrata como é um mapa estratégico construído com balanced scorecard.

Objectives and Key Results, OKR

O OKR assim como o BSC é uma ferramenta de apoio a estratégia mas criado por John Doerr também na década de 90. Ela se baseaia em um árvore de objetivos que podem estar ligados a outros objetivos e assim por diante. Cada objetivo deve ter um ou mais resultados-chave que deve ser considerado como cumprido para entender que o objetivo está cumprido. Por fim um resultado chave deve ter a ela ações associadas: que são projetos que movimentam o resultado chave no sentido do objetivo.

Esse modelo se popularizou quando o criador que já havia implantado esse modelo na Intel também implantou na então desconhecida Google, naquele momento. Atribui-se parte do sucesso do Google ao seu método de controle estratégico.

Conceitos de base para o DDD

Lei de Conway

Continuando no desejo de deixar clara a vinculação entre a estratégia da organização e a prática do DDD vamos falar um pouco sobre a Lei de Conway. Ela é de 1967 e é absolutamente verdadeira nos dias atuais. Ela considera que a forma em que a organização se comunica será a mesma forma em que um software será desenvolvido por dentro. Veja a seguir a citação formal

Qualquer organização que projeta um sistema ou solução, produzirá um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização.

Lei de Conway, 1967

Vamos pensar em alguns exemplos que justifiquem o que está sendo colocado. Organizações que possuem áreas de negócio que não se comunicam, isoladas e com relação limitada produzirá um software modular, com pouca comunicação entre as entidades dos domínios relacionados.

Agora, uma empresa que tenha um modelo e comando e controle, muito herarquizada mas com as áreas de um nível da hierarquia cooperando completamente os seus pares, mas subordinados ao superior e sobordinando aos demais: o software será hierarquizado, centralizado com domínios e estruturas muito comunicantes.

De alguma maneira algumas organizações tendem ao uso de monólitos uma vez que sua estrutura organizacional é, de algum modo, um monólito. Por outro lado há outras que tendem a ser modulares, microsserviços e afins. Veja também: Como funciona o sistema de recompensas do cérebro.

Veja a seguir uma imagem que ajuda a exemplificar esse ponto:

Complexidade natural versus complexidade acidental

Embora o conceito de complexidade natural e acidental não tenha uma pessoa considerada como criadora, vamos marcar como referência o artigo ‘No Silver Bullet: Essence and Accidents of Software Engineering‘ do Fred Brooks escrito em 1986. Esse artigo embora seja um pouco antigo ele é relevante e influencia a construção de softwares até os dias de hoje.

O autor comenta sobre o fato de que softwares lidam com complexidades, algumas naturais e outras acidentais. As naturais são aquelas que são a razão de ser do software e sem elas nada faz sentido. Em outras palavras estou falando do domínio ou regra de negócio. E por outro lado há aquilo que são meios para que as complexidades naturais sejam atendidas, como elementos de infraestruturas, camadas, abstrações, etc: Esses elementos são acidentes.

Há um entendimento de que a complexidade natural é a complexidade que importa e a única que existe com ou sem o software. As complexidades do legado e as específicas da solução técnica são aquelas que acidentam a solução mas que acabam sendo necessárias para a definição do software. A somatória dessas complexidades cria a real complexidade do software.

Linguagem ubíqua

Se a complexidade do software carrega elementos acidentais e naturais há de se esclarecer que desenvolvores são pensadores dos acidenetes. Eles são responsáveis, em última instância, a pensar o que fazer e como agir em relação ao legado ou às estruturas técnicas envolvidas. E por outro lado o especialista de domínio é quem carrega o domínio e suas características particulares do negócio.

Sendo assim é importante focarmos em o que realmente importa. A comunicação com o especialista do domínio revela coisas interessantes como termos que apenas ele usa, ou mesmo palavras que ele usa com um significado muito particular. Por exemplo, no mercado de marcas e patentes, um cliente nem sempre é o detentor da patente, mas sim um escritório de patentes parceiro, que por sua vez tem relação com o detentor. Já o detentor é conhecido como Titular.

A linguagem onipresente

Essas características indicam quais são as principais entidades envolvidas no domínio e quais são as ações associadas a tais entidades. A linguagem ubíqua ou linguagem universal é a linguagem falada específicamente pelo especialista do negócio em relação a um domínio em particular.

A linguagem ubíqua deve passar pela estratégia da organização, pelos especíalistas de domínio, pelos arquitetos de software, pelos desenvolvores e pelo software propriamente dito. Utilizar a mesma linguagem estabelece vantagens claras como a redução do custo de comunicação e desentendimentos.

Esse tema é tão relevante que o Erik Evans após ser inquirido pela pergunta: “Se você tivesse que fazer alguma alteração no seu livro DDD ‘atacando as complexidades no Coração do software’, o que você faria?” e ele responde: “Eu daria mais destaque à linguagem ubíqua.”

Aplicação do DDD estratégico

Domínio e sub-domínio

Pois bem, por um lado temos a estratégia da organização (BSC, ORK, etc.), por outro temos a estrutura das áreas e comunicação (Lei de Conway), e por outro temos a linguagem particular de grupos de conhecimento que representam as complexidades naturais. Esses fatores se consolidam em um grupo delimitado chamado domínio.

Para o DDD um domínio é um conjunto de regras de negócios, estruturas, conceitos e relações associadas a um negócio em específico. Por exemplo, um banco é um domínio; um escritório de advogados é outro, e assim por diante.

Um domínio tem nele um conjunto de entidades. Uma entidade é um objeto do negócio que possui identidade: é algo do mundo real, e de fato é significativo. Pois bem, alguns exemplos são: usuários, clientes, funcionários, produtos, entre outros. Algumas entidades se interrelacionam diretamente e são notáveis por que são escopo de conhecimento e de trabalho de um especialista de negócio. De modo geral entendemos que essas entidades formam ou podem formar um sub-domínio.

Tipos de domínio

A ideia é fazer uma separação clara de grupos de conhecimento afins de modo que seja óbvio e prático para qualquer interessado nevegar pelos pontos de interesse do software. Para o DDD há três tipos específicos de domínio: Core domain (é a razão de ser do negócio), o Generic Domain (um domínio de apoio ao core. Ele é muito útil), e o Support Domain (não é um diferencial e é candidato a ser substituído por produtos de prateleira).

Veja a seguir um exemplo de um domínio de um banco com os seus sub-domínios separados pelos tipos indicados anteriormente:

Context Map e modelagem estratégica

Agora estamos chegando no final dos conceitos estratégicos associados ao DDD e entrando no limite dos conceitos táticos: que não serão abordados ou detalhados nesse artigo, mas sim num outro especializado no tema.

A modelagem estratégica dos domínios é composta por domínios e sub-domínios, como já comentado, mas também por entidades e bounded contexts (contextos delimitados). As diferentes entidades se relacionam e são divididas em contextos que são limitados, de modo geral, pelo especialista de domínio. Quando é necessário falar com outro especialista de domínio é por que trata-se de outro contexto.

O exemplo a seguir demonstra dois contextos: um de vendas e outro de suporte aos clientes, que têm suas várias entidades. Porém note que há as entidades customer e product que existem em ambos os contextos: isso está completamente correto. Nesse cenário é provavel que as características e comportamentos da entidade Customer do contexto de vendas seja diferente da Customer do Support. Embora tenham o mesmo nome são coisas ligeiramente diferentes.

Tipos e relação entre as entidade

A relação entre as entidades possuem nomes e características que precisam ser destacadas. Por exemplo, um banco que precisa se adequar a definições do BACEN or regras que podem surgir a qualquer momento, costuma ter uma área/domínio específico chamado regulatório que lida com esse tema. Quando o BACEN faz uma nova regra o banco precisa se adaptar e não há o que negociar. Entendemos que nesse caso há uma relação Conformist (conformista).

Por outro lado, podemos ter uma relação em que o estoque é atualizado a partir da venda de um produto. Pode-se haver uma relação de Partner (parceira) quando há um acordo e alterações de A para B ou B para A podem ocorrer.

Há também relações onde há um Shared Kernel (Núcleo Compartilhado), onde regras e estruturas são compartilhadas por entidades distintas.

Conclusão

Começamos observando a estratégia corporativa, BSC, ORK e como eles estruturam organizações. Depois comentamos sobre as complexidades do software, a lei de conway e como isso pode se relacionar com o DDD. A partir daí entramos diretamente no DDD destacando a linguagem ubíqua como o ponto mais fundamental do modelo que se decompoe em domínios, sub-domínios, bounded contexts e entidades.

Esse é o método mais completo para lidar com as complexidades da construção de um software se relacionando fundamentalmente às necessidades da estratégia da organização, potencializando a entrega de valor. Certamente esse artigo não explora todo o tema, por ser muito vasto, mas oferece uma boa visão geral.