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?

"Apagão de talentos na área de TI? Que absurdo."

"Apagão de talentos na área de TI? Que absurdo."

Essa é a reação padrão de muitos profissionais de TI quando alguém diz que há um apagão de talentos na área de TI. Muitos verdadeiros talentos acreditam não estarem isolados, embora creio que a maioria se sinta assim. Já outros, talentos fajutos, que por alguma razão se consideram talentos natos mas que mal conseguiriam elaborar uma boa redação, se ofendem e partem pro ataque.

Não tenho em mãos dados estatísticos ou qualquer outra evidência forte de que esse apagão de fato exista, no entanto posso falar pela minha percepção. Já faz uns 8 anos que sou um dos responsáveis pela seleção de desenvolvedores e testadores de software nas empresas em que trabalhei nesse período, e o que observo é assustador. Sempre fui muito exigente e os exames de seleção que costumo aplicar refletem isso, no entanto sou criterioso o bastante para não exagerar e a impressão que fica é que a cada 10 que se candidatam, apenas 1 ou 2 merecem se quer serem considerados.

O mercado de TI nos últimos anos, em especial na área de desenvolvimento de software, tem se inflado cada vez mais de "profissionais" acomodados, que aprendem a fazer o básico, muitas vezes usando uma única tecnologia, uma única linguagem, um único framework, e mesmo assim escrevendo códigos de péssima qualidade mas que por já terem feito CRUDs por alguns poucos anos se consideram profissionais experientes. Há muitos profissionais de desenvolvimento de software no mercado, alguns são realmente bons e me daria orgulho os terem como colegas de trabalho, no entanto o que percebo é que são minoria (minoria no mercado como um todo, pois se considerar apenas os que participam ativamente das comunidades online de desenvolvedores creio que o número cresça bastante, pois apenas por estarem participando delas já podem ser considerados mais interessados pela profissão que os demais).

Portanto, o que penso é que há sim um apagão de talentos na área de TI, embora haja um excesso de profissionais disponíveis no mercado. E as más condições de trabalho e baixos salários pagos em alguns segmentos do setor em algumas cidades do país não servem como desculpa para o desapego e a falta de compromisso com a carreira que muitos demonstram. Pelo contrário, a baixa valorização pode até ser em parte justificada pelo excesso de maus profissionais, que aceitam qualquer condição de trabalho, desde que não exijam muito em troca.

Enfim, se quer saber o que eu espero de um profissional, veja este link e este link.