Procedimentos armazenados são detalhes de implementação. Funções de banco de dados, lambdas ou um script de shell armazenado em algum lugar no sistema de arquivos são todos detalhes da implementação e irrelevantes para a arquitetura.
a maioria dos livros sobre microsserviços recomenda um banco de dados por microsserviço.
Ok, para que possamos codificar os procedimentos armazenados nesses bancos de dados.
mais uma vez, a maioria dos livros de arquitetura de microsserviço declara que eles devem ser autônomos e com pouca conexão
Entre os recursos de negócios, os ciclos de vida do desenvolvimento, o gerenciamento, as implantações, os locais das equipes etc. Nada a ver com os detalhes da implementação. Os microsserviços não resolvem um problema técnico (exatamente o oposto). Eles vêm para resolver problemas com a administração e o tempo de colocação no mercado. É uma estratégia, não uma tática. Uma maneira de obter falhas com o menor custo possível. Se um determinado recurso de negócios é inútil, nós o descartamos sem prejudicar outros recursos, implantações, gerenciamento de projetos, lançamentos ...
Observe que a "divisão" já atua como um agente de desacoplamento. Digamos que temos dois serviços, A é suportado pelo Oracle e B pelo MongoDB. Se não violarmos a regra de ouro da dissociação, deve ser possível descartar o A + Oracle com efeitos colaterais desprezíveis em B.
O uso de procedimentos armazenados escritos digamos especificamente no Oracle, acopla firmemente o microsserviço a essa tecnologia.
Isso pode causar o bloqueio do fornecedor. Muitas vezes, o fornecedor é imposto pelo negócio por razões históricas ou contratuais 1 . É importante saber como não bloquear nosso código para o fornecedor. Por exemplo, alguns ORM e estruturas implementam uma nova linguagem de consulta que oculta as funções e os recursos internos do banco de dados.
Embora nossos serviços sejam suficientemente micro, o aprisionamento de fornecedores não é mais um problema, pois afeta uma pequena parte do todo. Uma pequena peça que deve ser possível ser substituída (ou isolada) rapidamente.
a maioria dos livros da MSA (que eu li) recomenda que os microsserviços sejam orientados para os negócios (projetados usando DDD).
Deve ser direcionado aos negócios e aqui está a coisa. Nem todas as empresas aproveitam o DDD. DDD e microsserviços se sobrepõem em muitos pontos, mas eles não são causa-efeito. Poderíamos acabar com um ecossistema de microsserviços composto por serviços anêmicos. Ou composto de uma mistura de ambos: serviços implementando um domínio complexo e serviços anêmicos mudos, fornecendo POJOs diretamente do DB. Não há nada de errado nisso.
Em relação aos livros, eles se concentram apenas na execução da estratégia. As táticas - como tirar proveito da computação distribuída - como fazê-la funcionar com sucesso, mas são (geralmente) agnósticas à estratégia. As estratégias variam de empresa para empresa e raramente dependem dos desenvolvedores. Portanto, ainda precisamos extrapolar e adaptar o que os livros dizem às nossas necessidades, exigências e restrições específicas. O objetivo é tornar a estratégia de negócios rentável e sustentável.
Lembre-se sempre de que qualquer arquitetura é um meio para atingir um fim. As regras de negócios. Não construímos ecossistemas de microsserviços para moda ou amor à arte.