2

Je pense à une architecture de microservice orientée DDD comme décrit dans cet article (https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/ddd-oriented-microservice). Mais je doute de l'accès aux données et des entités.Dans un microservice orienté DDD, l'infrastructure et les entités peuvent-elles être réutilisées?

Serait-il logique pour moi de mettre des entités de domaine et l'accès aux données dans un projet commun ou même dans un nugget? Parce que je pense que je réécrirais le même accès aux données plusieurs fois pour chaque service.

Répondre

2

Peu importe si vous utilisez DDD ou non, les quatre principes de la SOA sont:

  • services ont des limites explicites
  • services sont autonomes
  • services schéma d'actions et le contrat, pas de classe
  • Services interopérationnels basés sur la politique

L'un des Les conséquences en sont que les services ne partagent jamais leur persistance. Il y a des discussions sur la façon dont les limites de service s'alignent avec des contextes bornés, mais vous pouvez commencer simple et avoir un alignement un-à-un pour commencer et un contexte borné est aussi quelque chose qui n'expose jamais sa persistance .

3

TL; DR: no.

Les micro-services doivent communiquer entre eux à l'aide d'API.

Deux raisons:

  • services Micro que les racines globales définissent des limites claires transactionnelles. Réutiliser le code signifie potentiellement prendre un raccourci qui esquive les préconditions, les post-conditions et les vérifications invariantes.
  • Deuxièmement, le partage de code vous oblige à intégrer les modifications au modèle avec tous les micro-services dépendant, ce qui peut aller à l'encontre du but de l'adoption des micro-services. Avoir une version API différente vous aidera à gérer cela progressivement.