Um grande marco para a indústria de software foi a publicação de “Domain-Driven Design: Atacando as complexidades no coração do software” de Eric Evans, 2003, o qual trazia a ideia de que o funcionamento do negócio deveria guiar o desenvolvimento do software.

O livro de Evans é também conhecido por ser de difícil leitura e por isso outras obras foram publicados com a intenção de transmitir as ideias de Domain-Driven Design para o público leigo. Um desses livros é “Aprenda Domain-Driven Design: Alinhando Arquitetura de Software e Estratégia de Negócios” de Vladimir Khononov. O conteúdo presente no texto de Khononov será aqui resumido em 3 posts. Cada post aborda uma seção do livro. A primeira seção, assunto deste post, aborda uma visão de entendimento do negócio a partir de padrões, ditos estratégicos.

Análise do negócio

O foco de DDD é a produção de um sistema de software que seja organizado a partir de um entendimento da empresa. Logo, para iniciarmos, é necessário entender qual a área de atuação da empresa. Vendas? Segurança? Transporte? Qual o domínio que a empresa atua?

Podemos dar mais um passo em direção do entendimento da organização ao pensar em como as partes se organizam para formar um todo coeso. Pela teoria do DDD, o domínio se divide em 3 partes: principal, suporte e genérico.

Subdomínio Principal

Este é a causa dos ganhos financeiros da empresa. Qual é o diferencial da empresa? Onde está a vantagem da empresa ante as outras? Qual a complexidade que a empresa entrega com simplicidade para o cliente?

O diferencial da empresa é onde estão os esforços de desenvolvimento e pesquisa. É uma solução desenvolvida pela própria empresa.

Imagine uma empresa de venda de produtos online. O marketplace, a negociação dos produtos é o subdomínio principal.

Subdomínio de Suporte

Neste subdomínio estão as áreas de base para os subdomínios principais. Normalmente, esta área é complexa demais para que existam soluções prontas e, por isso, faz-se necessário a produção pela própria empresa. Além disso, a lógica de negócio desse subdomínio não é complexa. Por não serem áreas críticas, provavelmente, não recebem tanto investimento quanto as principais. Podemos pensar em setores que produzem bibliotecas internas não críticas para outras equipes da empresa.

Subdomínio Genérico

Aqui estão os subdomínios que todas as empresas fazem igual, não há realmente vantagem competitiva. No mercado, existem soluções prontas que já satisfazem a necessidade da organização, em termos funcionais e financeiros. Um exemplo seria a utilização de sistema de gerenciamento de RH. Vale ressaltar que, para a empresa que vende o software, esse seria um subdomínio principal, mas para todas as outras é um subdomínio genérico.

Comparando os tipos de subdomínio

Em linhas gerais, podemos dizer que:

1. O subdomínio principal é a fonte de diferenciação do negócio frente outras empresas, além de possuir uma complexidade alta de desenvolvimento.

Especialistas de domínio

1. O subdomínio genérico não é fonte de diferenciação pro negócio, muitas empresas já o fazem. A complexidade pode ser alta, mas como já existe uma solução pronta que satisfaz as necessidades, utilizasse ela mesmo.
2. O subdomínio de suporte é fonte de diferenciação e é complexo.

O conhecimento sobre o negócio não está presente somente na estrutura da empresa, mas, obviamente, inclui as pessoas, principalmente, os chamados “Especialistas de Domínio”, pessoas que trabalham e vivem o dia a dia do negócio. A partir delas, os engenheiros conseguem entender e derivar os principais casos de uso, regras e necessidades para o negócio consiga fluir.

Linguagem ubíqua

No método tradicional de desenvolvimento, especialistas de domínio traduzem o funcionamento esperado do software em um documento de requisitos que será analisado pelas pessoas responsáveis pelo desenvolvimento da solução. Na prática, ocorre um transformação do conhecimento em diversas formas, o que pode levar a perdas de informações que afetarão o funcionamento do sistema.

Pensando neste problema, o DDD traz um padrão de comunicação chamado linguagem ubíqua. O time de desenvolvimento deve estar conectado e em estreita comunicação com os especialistas internalizando seus modelos mentais. Isso significa internalizar e, por consequência, utilizar o mesmo vocabulário que o negócio em todos os lugares possíveis, como em conversas entre engenheiros, nas documentações, nos testes e no código. Vocabulário o qual precisa ser o mais objetivo e claro possível, sem ambiguidades. E quanto mais complexo o negócio, mais necessário e recorrente deve ser os encontros entre os times.

Contextos delimitados e como se relacionam

A partir da utilização e absorção da linguagem ubíqua pelos desenvolvedores, certo problema começa a aparecer: os especialistas utilizam termos semelhantes com definições distintas ou termos diferentes com a mesma definição. As conversas de negócio conseguem se desenrolar sem muitos problemas mas os engenheiros ficam sem entender. As reuniões possuem continuidade, pois os especialistas entendem o contexto em que o jargão é utilizado.

Como consequência, para o software se alinhar com o negócio, a solução de software será seccionada em conjuntos coesos. Isso pode lembrar os domínios mencionados acima, mas neste a seção será feito de forma consciente, será uma escolha dos desenvolvedores. Tais conjuntos são chamados pela teoria de Contextos Delimitados. São os projetos que os desenvolvedores modelam o(s) domínio(s). E como qualquer modelo, há diferença nos níveis de detalhe necessários para a correta implementação e funcionamento da solução.

Os contextos delimitados podem ser vistos como os projetos, repositórios, da empresa. Cada contexto deve ser cuidado por apenas 1 equipe e 1 equipe pode cuidar de mais de 1 contexto delimitado.

Pensando em como os contextos irão se comunicar, existem algumas estratégias: cooperação, cliente-fornecedor e caminhos separados.

Cooperação

A relação cooperativa entre contextos delimitados se dá pelo uso mútuo de certa modelagem/API mas em que o desenvolvimento é responsável por uma equipe. As mudanças são gerenciadas de forma livre. Espera-se que não haja conflitos para que seja possível o desenrolar do desenvolvimento da solução.

Outra forma de cooperação é de escopo compartilhado, o qual 2 ou mais equipes compartilham o desenvolvimento e uso de uma mesmo núcleo de modelagem. Alterações afetam imediatamente os contextos que a utilizam. Em certo sentido, isso quebra a ideia de contextos delimitados bem definidos e independentes. Por isso, é mais utilizado quando o preço da duplicação de conhecimento é mais caro que o trabalho de integração entre as equipes.

Cliente-Fornecedor

Basicamente, fornecedor é o contexto que mantém e distribui a interface, também dito ascendente. Já o cliente, utiliza a interface, também conhecido como descendente. As abordagens se dividem da seguinte forma.

Conformista

No padrão conformista, o cliente aceita e se adapta às mudanças feitas pelos fornecedores das API. Isso acontece quando, por exemplo, há conexão com bibliotecas de fora da organização. Para se proteger quanto a mudanças na interface pública, uma Camada de Anti-Corrupção é utilizada.

Serviço de host aberto

Neste padrão, a hierarquia inverte e o produtor não pode modificar a seu bel prazer. Uma prática para maximizar a proteção ao cliente é o uso de uma interface pública que caminha em um ritmo diferente da implementação interna.

Caminhos separados

Pode ser necessário que os contextos não se comuniquem. Normalmente, pela dificuldade de integração entre equipes. Mas, também, por necessidade de negócio:

• Talvez seja mais simples de integrar uma solução já existente em cada contexto delimitado, como por exemplo, uma biblioteca de log.
• Os modelos são tão diferentes que não faz sentido a integração.

Esse padrão deve ser evitado em integração de subdomínios principais, pois isso diminuiria efetividade e otimização do desenvolvimento das ideias de negócio.

Conclusão

DDD é um assunto amplo, muito discutido e complexo, logo esse post é uma introdução de um conhecimento que ajuda a sistematizar o entendimento e tradução do negócio para o mundo tecnológico. Nos próximos post, abordarei sobre os padrões estratégicos e outros temas do livro. Até mais!