Dans l'architecture DDD typique, nous avons 3 projets:
Domaine - aucune référence
Application - il fait référence au projet de domaine
Infrastructure - il fait référence au projet de domaine
(+ Projet Web / UI)
Les modèles de domaine vivent bien sûr dans le projet de domaine. Mais dans quel projet devrait-il vivre des modèles de lecture (projections) pour une base de données de lecture, par exemple MongoDb?
3 Réponses :
Réponse courte, les services d'application (couche application) et les référentiels (couche infrastructure) connaissent les modèles READ. La couche de domaine reste transparente aux mécanismes de persistance et de chargement sous-jacents.
Réponse longue, le mécanisme d'utilisation exact dépend de la manière dont vous utilisez les modèles lus. Vous pouvez soit les utiliser pour construire des objets utilisés dans votre couche de domaine, soit plus généralement, uniquement en tant que réponses aux requêtes API.
Premier cas: utilisez Read Models comme objets dans le calque de domaine
Le service d'application charge le modèle READ du référentiel dans l'entité de domaine. Il est de la responsabilité du référentiel de remplir correctement le modèle READ dans l'entité de domaine. Le référentiel est également responsable de la transformation de l'entité de domaine en modèle WRITE pour qu'elle persiste dans la base de données primaire.
Au moment où vous accédez au modèle de domaine, les objets sont déjà chargés en mémoire à l'aide de référentiels. Ainsi, la couche de domaine ne connaît même pas le modèle READ et un modèle WRITE; il ne traite que de l'entité de domaine.
Deuxième cas: utilisez Read Models pour stocker des réponses prédéfinies aux requêtes API
Ce scénario est une utilisation plus typique des modèles READ. Habituellement, il existe plusieurs modèles de lecture pour la même entité / agrégat, car ils sont conçus sur mesure pour des demandes d'API spécifiques.
Dans ce cas, nous ne touchons même pas la couche de domaine. Le service d'application accepte la demande, utilise le référentiel de modèles READ pour charger l'objet et renvoie une réponse au serveur d'application.
Dans l'approvisionnement d'événements, les modèles de lecture ne représentent pas les entités de domaine par définition. La seule source de vérité est le flux d'événements de cette entité.
Bon point, @AlexeyZimarev. J'aurais dû mentionner que je parlais d'instantanés intermédiaires de données, de capture à partir du flux d'événements. Même dans ce cas, vous avez raison de dire que les modèles lus ne jouent aucun rôle dans la couche de domaine.
J'imagine que vous utilisez un modèle de lecture comme source de données pour certains services de domaine. Ce n'est peut-être pas idéal mais toujours légitime. Cela étant dit, j'essaierais d'éviter d'utiliser le modèle de lecture comme source principale de tout type d'informations pour prendre des décisions dans le domaine. L'entité ou l'agrégat doit contenir suffisamment d'informations pour prendre cette décision.
Se mettre d'accord. Jusqu'à présent, dans toutes mes implémentations, les modèles de lecture n'ont été utilisés que pour les réponses API pré-préparées. Et le plus souvent, il existe plusieurs modèles de lecture pour la même entité ou agrégat. Comme je l'ai souligné dans ma réponse, l'utilisation de modèles de lecture dans le premier cas n'est pas un cas typique, bien que cela soit possible. Nous sommes donc synchronisés dans notre processus de réflexion.
Pour être honnête, cela n'a pas vraiment d'importance. Il n'y a pas de structure par défaut ni pour l'implémentation orientée DDD ni pour l'implémentation orientée source d'événements.
Vous pouvez parfaitement avoir un seul projet si le système est petit. Si vous voulez garder votre domaine exempt de références externes, vous pouvez le conserver dans un projet séparé et vous assurer de n'avoir aucune référence, sauf pour quelque chose dont vous avez besoin pour prendre en charge la base du modèle de domaine, comme la classe de base d'entité, etc.
Les modèles de lecture et les projections sont complètement orthogonaux au modèle de domaine et vous en avez généralement besoin pour l'API de requête ou les services de requête. Vous bénéficierez de la conservation des modèles lus (documents dans le cas de MongoDB) et des projections en un seul endroit. Vous pouvez référencer ce projet à partir de votre projet d'API ou conserver ensemble l'API de requête, les services de requête, les modèles de requête, les modèles de lecture et les projections.
Encore une fois, je dirais qu'une telle chose comme une "architecture DDD typique" n'existe pas, parce que DDD n'est pas une architecture au départ. Le fractionnement des projets est davantage un souci de commodité et de discipline pour les développeurs et le fractionnement du système est un problème d'architecture, qui n'est pas spécifique à DDD.
Une chose qui me vient également à l'esprit est que si vous pensez vraiment à DDD, vous voudrez peut-être d'abord savoir quelle est votre carte de contexte, de combien de modèles de domaine vous avez vraiment besoin et peut-être que vous y êtes peut trouver des idées sur la séparation, qui ne sont pas vraiment basées sur des préoccupations techniques.
Il n'y a pas de loi écrite qui dicte dans quel projet un modèle de lecture doit vivre. À mon avis personnel, je pense qu'avoir un projet de modèle de lecture séparé a ses avantages. Avec la séparation des responsabilités des requêtes de commande, les choses ont tendance à devenir assez déroutantes si la partie commande de l'application peut accéder à la partie requête de l'application. Je pense que les deux devraient être clairement séparés.
J'ai passé du temps à travailler sur un exemple de projet qui montre comment configurer votre application DDD / ports-and-adapters / CQRS. J'ai déposé le code sur GitHub: https://github.com/appie2go/steal-this -code
J'ai également passé du temps à expliquer en détail les choix que j'ai faits dans les articles suivants:
J'espère que cela aide!
Acclamations