Les procédures stockées sont des détails de mise en œuvre. Les fonctions de base de données, les lambdas ou un script shell stocké quelque part dans le système de fichiers sont tous des détails d'implémentation et sont sans intérêt pour l'architecture.
la plupart des livres sur microservices recommandent une base de données par microservice.
Ok, nous pouvons donc coder les procédures stockées dans ces bases de données.
encore une fois, la plupart des livres d’architecture de microservices indiquent qu’ils devraient être autonomes et couplés de manière lâche
Entre les capacités de l'entreprise, les cycles de vie du développement, la gestion, les déploiements, les emplacements des équipes, etc. Rien à voir avec les détails de la mise en œuvre. Les microservices ne résolvent pas un problème technique (au contraire). Ils viennent résoudre les problèmes de gestion et de time-to-market. C'est une stratégie, pas une tactique. Un moyen d'échec rapide avec le moins de coûts possible. S'il s'avère que certaines fonctionnalités de l'entreprise ne servent à rien, nous les abandonnons sans compromettre les autres fonctionnalités, déploiements, gestion de projets, versions ...
Notez que la "scission" agit déjà comme un agent de découplage. Supposons que nous ayons deux services, A est pris en charge par Oracle et B par MongoDB. Si nous ne respectons pas la règle d'or du découplage, il devrait être possible d'abandonner A + Oracle avec des effets secondaires négligeables sur B.
En utilisant des procédures stockées écrites spécifiquement dans Oracle, associe étroitement le microservice à cette technologie.
Cela pourrait causer un blocage du vendeur. Souvent, le fournisseur est imposé par l'entreprise pour des raisons historiques ou contractuelles 1 . Il est important de savoir comment ne pas verrouiller notre code au fournisseur. Par exemple, certains ORM et certains frameworks implémentent un nouveau langage de requête qui masque les fonctions et fonctionnalités intégrées à la base de données.
Bien que, si nos services sont suffisamment micro-économiques, le blocage des fournisseurs n’est plus un problème car il n’impacte qu’une petite partie de l’ensemble. Une petite pièce qui devrait pouvoir être remplacée (ou isolée) rapidement.
la plupart des livres de MSA (que j'ai lus) recommandent que les microservices soient orientés métier (conçus avec DDD).
Il devrait être axé sur les entreprises et voici la chose. Toutes les entreprises ne profitent pas de DDD. DDD et microservices se chevauchent sur de nombreux points, mais ils ne sont pas une cause à effet. Nous pourrions nous retrouver avec un écosystème de microservices composé de services anémiques. Ou composé d’un mélange des deux: services mettant en œuvre un domaine complexe et services anémiques produisant des POJO directement à partir de la base de données. Il n'y a rien de mal à ça.
En ce qui concerne les livres, ils se concentrent uniquement sur l'exécution de la stratégie. La tactique - comment tirer parti de l’informatique distribuée - comment la faire fonctionner avec succès, mais elle est (généralement) agnostique vis-à-vis de la stratégie. Les stratégies varient d'une entreprise à l'autre et dépendent rarement des développeurs. Il nous reste donc à extrapoler et adapter ce que les livres disent à nos besoins, exigences et contraintes spécifiques. L'objectif est de rendre la stratégie commerciale rentable et durable.
Gardez toujours à l'esprit que toute architecture est un moyen d'atteindre un but. Les règles de l'entreprise. Nous ne construisons pas d'écosystèmes de microservices pour la mode ou pour l'amour de l'art.