Criando uma loja virtual usando microsserviços

O Domain-Driven Design (DDD) é a abordagem de desenvolvimento de software que nos permite traduzir domínios de problemas complexos em software rico, expressivo e em evolução. É a maneira como projetamos aplicativos quando as necessidades de nossos usuários são complexas.

Você já trabalhou em uma base de código em que parecia "quanto mais código você adicionava, mais complexo o código ficava"?

Alguma vez você já se perguntou, "como organizar a lógica de negócios" ?

Ou você já esteve na situação em que ficava nervoso para adicionar um novo código a uma base de código existente com medo de quebrar algo em uma parte completamente diferente do código em algum lugar?

Por isso o Domain-Driven Design é um conceito que você deve conhecer – não importa se você é um desenvolvedor ou especialista em domínio. Assim você estará apto a enfrentar projetos de software complexos com DDD.

O subtítulo do livro de Eric Evans fornece uma dica muito boa:
"Lidando com a complexidade no coração do software"

Normalmente, a complexidade crítica dos projetos de software está no próprio domínio e você não pode alterar a complexidade dentro do domínio. Além disso, não desenvolvemos software apenas com o propósito de desenvolver software. Fazemos isso para resolver problemas e melhorar as coisas.

O coração do software é sua capacidade de resolver problemas relacionados ao domínio para seu usuário. Todos os outros recursos, por mais vitais que sejam, apóiam esse propósito básico.

O DDD não pode ser definido em uma frase ou duas. É uma abordagem para o desenvolvimento de software complexo que consiste em várias peças de quebra-cabeça como:

Esses três pontos já são um resumo de alto nível do DDD, e veremos cada um mais adiante.

Antes de começar a programar, fale com quem conhece e trabalha com o negócio com o domínio. Eles podem ajudar você a definir todos os processos, procedimentos e terminologia do domínio em questão.

Por exemplo: se você for projetar um software para gerenciar o estoque no varejo, converse com quem gerencia o estoque da loja em vez dos funcionários do RH ou de finanças, são eles que conhecem o dia a dia de como o domínio funciona na prática.

Entretanto não devemos confundir 'foco no domínio' com "foco no negócio". A complexidade e a oportunidade centrais podem ser diferentes do que chamaríamos de "o negócio".

Pense no Twitter. Fornecer a funcionalidade de Tweets, seguir uns aos outros, etc. não era a principal complexidade. Muito provavelmente, a principal complexidade estava mais no dimensionamento da plataforma.

Os modelos são uma forma de lidar com a complexidade acima mencionada. Mas, antes de mais nada, o que é mesmo um modelo?

Um modelo pode ser visto como um sistema de abstrações que descreve aspectos selecionados de um domínio e pode ser usado para resolver problemas relacionados a esse domínio.

Outra maneira de descrever o termo (também do próprio Eric Evans):

Um modelo é uma simplificação. É uma interpretação da realidade que abstrai os aspectos relevantes para resolver o problema em questão e ignora detalhes irrelevantes.

Assim, um modelo não é um diagrama (não é um Entity Relationship Diagram (ERD) - embora entidade também seja um termo usado em DDD). Um diagrama apenas ajuda a comunicar o modelo e temos muitos diagramas no contexto do DDD mas não existe uma linguagem de modelagem específica e única. Na maioria das vezes, alguns diagramas da UML são usados ou apenas um esboço manuscrito. Não é sobre o diagrama, mas sobre o conceito por trás dele.

Projetos grandes geralmente têm muitos modelos que precisam ser integrados. O limite do contexto define a estrutura lógica na qual o modelo pode evoluir. Assim, as outras equipes sabem o que fazer para que os modelos delas sejam válidos quando adicionados a outros.

Outro fator importante é que não existe isso de terminar os modelos de uma vez por todas; será um processo iterativo chegar a um modelo, e, haverá novos insights, problemas novos ou mutáveis no domínio ou qualquer outra coisa. É uma exploração contínua.

O que significa linguagem ubíqua no contexto do DDD ?

A linguagem ubíqua é uma linguagem estruturada em torno do modelo de domínio e usada por todos os membros da equipe dentro de um contexto limitado para conectar todas as atividades da equipe com o software.

Aqui temos um termo que vale a pena definir: contexto limitado.

O Contexto significa a configuração em que uma palavra ou declaração aparece que determina seu significado. As declarações sobre um modelo só podem ser entendidas em um contexto.

O Contexto limitado é uma descrição de um limite (normalmente um subsistema ou o trabalho de uma equipe específica) dentro do qual um modelo específico é definido e aplicável.

Vale a pena notar que a linguagem "ubíqua" não é onipresente no sentido de ser aplicável em todo o sistema. Trata-se antes de usar em código, fala, diagramas, etc. É também por isso que a restrição "dentro de um contexto limitado" é adicionada.

A linguagem será aplicável dentro do limite que você deve definir explicitamente. Não se trata de definir termos além das fronteiras, por exemplo. para toda a empresa. A linguagem ubíqua é uma linguagem comum diretamente interconectada com o modelo de um determinado domínio, que é usada em todos os lugares dentro de seus limites definidos.

Em um projeto sem uma linguagem comum, os desenvolvedores precisam traduzir para os especialistas de domínio, e, os especialistas de domínio traduzem entre desenvolvedores e ainda outros especialistas de domínio e os desenvolvedores até traduzem uns para os outros.

Aposto que você encontrou situações em que você, como desenvolvedor, não tinha ideia do que o especialista do domínio estava falando ou, pior ainda, você achava que sabia, mas ele estava falando de outra coisa. O mesmo acontece ao contrário.

Criar o hábito de perguntar o significado de termos específicos que estão sendo usados é muito importante, e, a linguagem ubíqua tem que ser exercida pela equipe em toda a comunicação de forma implacável.

Se o especialista do domínio está falando sobre um conceito no domínio que não está refletido no modelo, o modelo provavelmente está incompleto.

Dessa forma a linguagem onipresente fará com que o código e o domínio real se aproximem. Não se trata apenas do código que reflete o domínio real, também tem alguns outros aspectos positivos como a manutenibilidade do código.

Se outro desenvolvedor voltar ao código depois de um tempo, haverá termos usados no domínio. Os especialistas de domínio têm o conhecimento sobre os termos usados, não são apenas classes com nomes criados pelos desenvolvedores.

Então, o DDD ainda é um conceito importante para se ter em seu cinto de ferramentas. E você vai usá-lo para os projetos apropriados.

Assim, resolver problemas do domínio é o que o desenvolvimento de software significa e como tivermos que lidar com essa complexidade podemos aplicar o DDD para facilitar nossas vidas.

"Jesus dizia, pois, aos judeus que criam nele: Se vós permanecerdes na minha palavra, verdadeiramente sereis meus discípulos;"
João 8:31

Porque um menino nos nasceu, um filho se nos deu, e o principado está sobre os seus ombros, e se chamará o seu nome: Maravilhoso, Conselheiro, Deus Forte, Pai da Eternidade, Príncipe da Paz.

Isaías 9:6