Arquitetura de Microserviços e DDD

DDD já é velho conhecido de muitos desenvolvedores de software já há mais de 10 anos, no entanto o termo Microservices Architecture tem ganhado popularidade apenas recentemente.

Venho trabalhando em uma arquitetura de micro serviços, desenvolvida sobre o .NET Framework, já há quase 1 ano, desde antes da popularização do termo e até mesmo antes da publicação do Manifesto Reativo. No entanto, essa arquitetura tem se mantido desde o início bem aderente a esses dois conceitos.

Chamada aqui de Plataforma ST (nome real omitido), trata-se de uma arquitetura que permite que pequenos serviços de aplicação coexistam e se comuniquem entre si, de modo seguro, escalável e permitindo que novos serviços possam ser incluídos na plataforma a qualquer momento, complementando as funcionalidades já existentes. Note que não se trata de um único produto composto por múltiplos serviços relacionados, mas sim de uma plataforma de agregação de serviços. É possível haver uma instância da Plataforma ST agregando serviços de CRM, outra agregando serviços de ERP e outra para serviços de POS, cada uma dessas compondo um sistema distinto. Ainda assim, para cada uma delas, existe a possibilidade de se agregar novos serviços, incluindo alguns que sejam responsáveis exclusivamente pela interação entre esses diferentes sistemas.

Segundo as recomendações do DDD, módulos de um sistema, no nosso caso assemblies ou namespaces .NET, não devem conter no seu nome um nome de produto, mas sim a funcionalidade que ele provê, assim como devem conter como prefixo o nome da empresa que os desenvolveu. Assim, um módulo de gerenciamento de projetos ágeis desenvolvido pela empresa Contoso deveria ser nomeado com.contoso.agileprojectmanagement.applicationservice, de acordo com o que fora apresentado por Vaughn Vernon em Implementing Domain-Driven Design. No entanto, o padrão com.nomedaempresa se limita ao mundo Java, linguagem usada pelo autor para ilustrar o livro. Em projetos .NET, não há o costume de acrescentar o nome da empresa nos nomes dos módulos, e muito menos o prefixo com.

Ainda assim, poderíamos adaptar essa terminologia e nomear um dos nossos módulos de Contoso.AgileProjectManagement.ApplicationService, no entanto optei por usar ST.AgileProjectManagement.ApplicationService, e posso justificar essa decisão.

A Plataforma ST requer que os serviços desenvolvidos para executar sobre ela sigam um determinado padrão. Há uma classe abstrata ou no minimo uma interface que precisa ser implementada por todos os serviços, além disso eles precisam ser desenvolvidos levando em consideração o modo como a Plataforma ST irá gerir seu ciclo de vida. E mais, a Plataforma ST não é uma bala de prata, obviamente. Há cenários em que o mais interessante seja usar uma outra plataforma, ou desenvolver o sistema diretamente sobre o .NET Framework, já descartando os casos em que o próprio .NET Framework não seja a melhor opção.

Imagine por exemplo que seja desenvolvido na mesma empresa um sistema de colaboração, uma espécie de Wiki, que se adere aos padrões DDD mas não se encaixa na Plataforma ST. Esse sistema será desenvolvido de modo completamente independente dela, seus módulos serão totalmente incompatíveis. Agora seguindo a recomendação de usar o nome da empresa para determinar o nome dos módulos, teríamos algo como Contoso.Collaboration.ApplicationService, algo muito semelhante aos módulos dos sistemas desenvolvidos sobre a Plataforma ST, mas sem relação alguma com ela.

Por que não usar então Contoso.ST.AgileProjectManagement.ApplicationService? Ai vem um ponto em que discordo da recomendação do Vernon. Usar o nome da empresa, de qualquer modo que seja, na nomenclatura dos módulos, pode ser ruim e prefiro usar em seu lugar não o nome comercial de um serviço, o que concordo não ser recomendável, mas manter o módulo nomeado conforme sua função e prefixá-lo com um nome de projeto ao invés do nome da empresa. Seria algo que identifica todos os módulos que possuem algo em comum e cumpre a mesma função do nome da empresa na recomendação do livro.

Mas por que isso? Já trabalhei em uma empresa que mudou de nome, e via produtos legados com o nome antigo por todos os lados. Há casos de fusões e aquisições, em que o nome do proprietário do produto muda, e mesmo havendo motivações para manter o nome do desenvolvedor original mesmo que ele não exista mais, há o risco de novos módulos que integrem a mesma aplicação passarem a ser nomeados conforme o novo nome da empresa, o que geraria uma combinação de nomes de módulos não muito interessante.

Enfim, era isso que gostaria de compartilhar aqui e gostaria de ouvir a opinião de quem trabalha com DDD e já teve que passar por situações semelhantes às que descrevi. O que vocês tem a dizer?