Comment cela peut-il avoir un sens?
Réponse courte: ce n'est pas le cas .
Réponse plus longue: les modèles lourds de développement d'un modèle de domaine ne s'appliquent pas aux parties de votre solution qui ne sont qu'une base de données.
Udi Dahan avait une observation intéressante qui pourrait aider à clarifier cette
Dahan considère qu'un service doit avoir à la fois une sorte de fonctionnalité et des données. S'il n'a pas de données, alors c'est juste une fonction. Si tout ce qu'il fait, c'est effectuer des opérations CRUD sur des données, alors c'est une base de données.
Le but du modèle de domaine, après tout, est de garantir que toutes les mises à jour des données maintiennent l'invariant commercial actuel. Ou, pour le dire autrement, le modèle de domaine est chargé de s'assurer que la base de données qui agit comme système d'enregistrement est correcte.
Lorsque vous traitez avec un système CRUD, vous n'êtes généralement pas le système d'enregistrement des données. Le monde réel est le livre des records, et votre base de données n'est qu'une représentation localement mise en cache du monde réel.
Par exemple, la plupart des informations qui apparaissent dans un profil d'utilisateur, comme une adresse e-mail ou un numéro d'identification émis par le gouvernement, ont une source de vérité qui vit en dehors de votre entreprise - c'est l' administrateur de messagerie de quelqu'un d'autre qui attribue et révoque les adresses e-mail, pas votre application. C'est le gouvernement qui attribue les SSN, pas votre application.
Donc, vous n'allez normalement pas faire de validation de domaine sur les données qui vous viennent du monde extérieur; vous pourriez avoir des contrôles en place pour vous assurer que les données sont bien formées et correctement nettoyées ; mais ce ne sont pas vos données - votre modèle de domaine ne reçoit pas de veto.
Dans une approche DDD utilisant des couches, il semble que les opérations CRUD passent par la couche domaine. mais au moins dans notre cas, cela ne semble pas avoir de sens.
C'est le cas dans le cas où la base de données est le livre d'archives .
Ouarzy l'a exprimé ainsi .
Cependant, en travaillant sur beaucoup de code hérité, j'observe des erreurs courantes pour identifier ce qui est à l'intérieur du domaine et ce qui est à l'extérieur.
Une application ne peut être considérée comme CRUD que s'il n'y a pas de logique métier autour du modèle de données. Même dans ce (rare) cas, votre modèle de données n'est pas votre modèle de domaine. Cela signifie simplement que, comme aucune logique métier n'est impliquée, nous n'avons besoin d'aucune abstraction pour la gérer, et donc nous n'avons pas de modèle de domaine.
Nous utilisons le modèle de domaine pour gérer les données qui appartiennent à l'intérieur du domaine; les données provenant de l'extérieur du domaine sont déjà gérées ailleurs - nous ne faisons que mettre en cache une copie.
Greg Young utilise les systèmes d'entrepôt comme illustration principale des solutions où le livre d'archives est ailleurs (c.-à-d. L'étage de l'entrepôt). L'implémentation qu'il décrit ressemble beaucoup à la vôtre - une base de données logique pour capturer les messages reçus de l'entrepôt, puis une base de données logique distincte mettant en cache les conclusions tirées de l'analyse de ces messages.
Alors peut-être que nous avons deux contextes bornés ici? Chacun avec un modèle différent pour uninvestment account
Peut être. Je serais réticent à le marquer comme un contexte délimité, car il n'est pas clair quels autres bagages sont accompagnés. Il se peut que vous ayez deux contextes, ce pourrait être un contexte avec des différences subtiles dans le langage omniprésent que vous n'avez pas encore compris.
Test décisif possible: combien d'experts de domaine avez-vous besoin de deux experts de domaine pour couvrir ce spectre, ou d'un seul qui parle des composants de différentes manières. Fondamentalement, vous pourriez être en mesure de deviner combien de contextes délimités vous avez en travaillant la loi de Conway à l'envers.
Si vous considérez que les contextes délimités sont alignés sur les services, cela peut être plus simple: devriez-vous être en mesure de déployer ces deux fonctionnalités indépendamment? Oui suggère deux contextes délimités; mais s'ils doivent être synchronisés, alors peut-être que ce n'est qu'un.
