J'ai écrit cette réponse il y a environ quatre ans et mon opinion n'a pas changé. Mais depuis lors, il y a eu des développements importants sur le front des micro-services. J'ai ajouté des notes spécifiques aux micro-services à la fin ...
Je vais peser contre l'idée, avec une expérience du monde réel pour appuyer mon vote.
J'ai été amené à une grande application qui avait cinq contextes pour une seule base de données. En fin de compte, nous avons fini par supprimer tous les contextes, sauf un - revenir à un seul contexte.
Au début, l'idée de contextes multiples semble être une bonne idée. Nous pouvons séparer notre accès aux données en domaines et fournir plusieurs contextes propres et légers. Cela ressemble à DDD, non? Cela simplifierait notre accès aux données. Un autre argument est pour la performance en ce sens que nous n'accédons qu'au contexte dont nous avons besoin.
Mais dans la pratique, au fur et à mesure que notre application grandissait, bon nombre de nos tables partageaient des relations dans nos divers contextes. Par exemple, les requêtes vers la table A dans le contexte 1 nécessitent également de rejoindre la table B dans le contexte 2.
Cela nous a laissé quelques mauvais choix. Nous pourrions dupliquer les tableaux dans les différents contextes. Nous avons essayé cela. Cela a créé plusieurs problèmes de mappage, y compris une contrainte EF qui nécessite que chaque entité ait un nom unique. Nous nous sommes donc retrouvés avec des entités nommées Person1 et Person2 dans les différents contextes. On pourrait dire que c'était une mauvaise conception de notre part, mais malgré nos meilleurs efforts, c'est ainsi que notre application a réellement grandi dans le monde réel.
Nous avons également essayé d'interroger les deux contextes pour obtenir les données dont nous avions besoin. Par exemple, notre logique métier interrogerait la moitié de ce dont elle avait besoin dans le contexte 1 et l'autre moitié dans le contexte 2. Cela posait quelques problèmes majeurs. Au lieu d'exécuter une requête sur un seul contexte, nous avons dû effectuer plusieurs requêtes dans différents contextes. Cela a une vraie pénalité de performance.
Au final, la bonne nouvelle est qu'il a été facile de supprimer les multiples contextes. Le contexte est destiné à être un objet léger. Je ne pense donc pas que la performance soit un bon argument pour plusieurs contextes. Dans presque tous les cas, je crois qu'un seul contexte est plus simple, moins complexe et fonctionnera probablement mieux, et vous n'aurez pas à mettre en œuvre un tas de solutions pour le faire fonctionner.
J'ai pensé à une situation où plusieurs contextes pourraient être utiles. Un contexte distinct pourrait être utilisé pour résoudre un problème physique avec la base de données dans laquelle il contient en fait plus d'un domaine. Idéalement, un contexte serait un à un vers un domaine, qui serait un à un vers une base de données. En d'autres termes, si un ensemble de tables n'a aucun lien avec les autres tables d'une base de données donnée, elles devraient probablement être extraites dans une base de données distincte. Je me rends compte que ce n'est pas toujours pratique. Mais si un ensemble de tables est si différent que vous vous sentiriez à l'aise de les séparer dans une base de données distincte (mais vous choisissez de ne pas le faire), je pourrais voir le cas pour utiliser un contexte séparé, mais uniquement parce qu'il y a en fait deux domaines distincts.
En ce qui concerne les micro-services, un seul contexte a encore du sens. Cependant, pour les micro-services, chaque service aurait son propre contexte qui ne comprend que les tables de base de données pertinentes pour ce service. En d'autres termes, si le service x accède aux tables 1 et 2, et le service y accède aux tables 3 et 4, chaque service aurait son propre contexte unique qui inclut des tables spécifiques à ce service.
Je suis intéressé par vos pensées.