Décomposer les microservices: capacité commerciale vs domaine
Comme je l'ai lu, il existe deux modèles pour définir un microservice, par capacité commerciale et par sous-domaine . Mais je le trouve toujours très ambigu. Je suis confus sur la façon dont ces deux modèles se différencient. Les deux tournent autour d'activités impliquant un domaine de logique métier. Tous les composants de chaque service sont suffisamment petits pour être regroupés sans affecter les autres services. Quelqu'un pourrait-il me donner des explications supplémentaires sur ces deux-là?
Les commentateurs ont raison - il y a ici quelques définitions subjectives. Mais certains principes et concepts peuvent aider à raisonner sur les différentes approches.
Loi de Conway
Ce n'est pas strictement la définition d'origine, mais je pense que la distinction peut être mieux comprise en référence à loi de Conway :
Toute organisation qui conçoit un système (défini au sens large) produira une conception dont la structure est une copie de la structure de communication de l'organisation.
L'Inverse Conway Manouvre
Suite à cette réflexion, la Inverse Conway Maneuver a évolué:
La "manœuvre inverse de Conway" recommande de faire évoluer votre équipe et votre structure organisationnelle pour promouvoir l'architecture souhaitée. Idéalement, votre architecture technologique affichera l'isomorphisme avec l'architecture de votre entreprise.
La manœuvre de Conway inverse est une tentative de structurer votre organisation pour exploiter la loi de Conway afin d'obtenir une meilleure conception du système.
Décomposition par capacité commerciale
En comprenant ces concepts, nous pouvons considérer que la décomposition par Business Capability guide la conception du système en fonction de la structure de l'entreprise. Cela fait écho à la loi de Conway.
L'avantage de cette approche est qu'elle contribue à assurer l'alignement entre les équipes de développement et les unités structurelles de l'entreprise. L'inconvénient est que cela peut entraîner des inefficacités commerciales survenues avant la prise en compte d'un système automatisé dans la conception de votre système.
Décomposition par domaine
La conception pilotée par le domaine (DDD) fournit une suite d'outils et de méthodologies pour raisonner sur le domaine sous-jacent à portée de main, pour refléter la meilleure compréhension disponible du domaine dans la conception du logiciel et pour faire évoluer la conception du logiciel à mesure que la compréhension du domaine grandit et change. Les modèles stratégiques DDD guident la création d'un Context Map qui peut former la base de la décomposition de vos microservices.
À partir de là, nous pouvons considérer que la décomposition par domaine guide la conception du système en fonction d'une analyse des processus et des flux d'information.
L'avantage de cette approche est qu'elle peut conduire à une conception de système qui modélise étroitement la réalité de ce qui se passe (ou doit se produire). Espérons que la structure de l'entreprise s'aligne déjà sur cela - mais là où elle ne le fait pas, elle peut révéler des inefficacités dans la structure organisationnelle de l'entreprise existante.
Si vous avez une influence sur la structure organisationnelle, cela peut être une base pour utiliser la manœuvre Inverse Conway et vous permettre de faire évoluer le logiciel, les équipes de développement et les unités commerciales pour réaliser l'alignement.
Si vous ne le faites pas, vous pouvez finir par introduire des points de friction où la conception du système est mal alignée avec les capacités de l'entreprise.
Conclusion
La réalité est qu'aucune des deux approches ne s'exclut mutuellement - vous vous retrouverez probablement avec un compromis qui tentera d'équilibrer l'alignement avec les capacités de l'entreprise telles qu'elles sont déjà comprises et les domaines problématiques tels qu'ils sont révélés via un processus DDD.
Les capacités opérationnelles ne reflètent pas la structure organisationnelle individuelle. Ils représentent ce que fait l'entreprise (quelles sont ses capacités) sans préciser comment ils seront mis en œuvre. La structure organisationnelle fait partie du "comment"/mise en œuvre.
Si votre carte de capacités commerciales est structurée en fonction de votre structure organisationnelle, cela doit être évalué de plus près, sauf si bien sûr, vous créez d'abord la carte de capacités commerciales, puis changez la structure organisationnelle en conséquence.
J'ai traité à la fois les domaines et les capacités commerciales. Ils sont essentiellement les mêmes, selon le niveau auquel vous travaillez.