DDD | hiérarchie (mêmes types) | contrainte

Question

J'ai regardé 2 autres questions qui semblent liées:

• Is Aggregate Root with Deep Hierarchy appropriate in DDD?
• How to define DDD Aggregate root for hierarchical data structure?

Cependant, ils ne sont pas exactement les mêmes que ma situation; peut-être manquer l'aspect "contrainte".

Ma situation: J'ai un RA nommé «Étude», et une étude peut être organisée par grappe (empruntant au concept d'échantillonnage en grappes dans le domaine de l'enquête). Supposons que cette "Etude" prenne ce paramètre "clusteringDepth" (un entier) dans is constructor. Disons: je précise 3 (provinces, comtés, villes).

C'est juste une spécification. d'une étude. Lorsque vous effectuez une étude, vous créez une instance de StudyPlan basée sur l'étude. Donc, dans ce cas, j'aurai une instance de StudyPlan qui a une liste de provinces (grappes de premier niveau). Chaque province a une liste de comtés (clusters de deuxième niveau) et chaque comté a une liste de villes (clusters de troisième/dernier niveau).

Sur chaque grappe, vous pouvez joindre des informations sur les quotas et la plage de dates (en spécifiant le nombre d'entretiens que vous devez effectuer dans cette grappe et l'intervalle de dates pour les interviews). De toute évidence, un cluster parent doit conserver des invariants comme "la somme des quotas des clusters enfants doit être inférieure ou égale au quota de ce cluster". Ok ..., maintenant, la contrainte: vous pouvez planifier une interview avec un répondant. Pour cela, vous créez une instance de InterviewPlan. Mais ..., ce plan d'entretien ne peut être rattaché qu'à des clusters terminaux (de troisième niveau).

Bien sûr, il est facile d'implémenter cette contrainte (par exemple, dans la méthode addInterviewPlan d'un cluster, je vérifie si le cluster a un parent ou non). Mais ... pour une raison ou pour une autre ... Je pense que ce n'est pas un bon design DDD. Cette contrainte semble trop technique; ça ne va pas naturellement dans une conversation de domaine normal.

Ma question: est-ce que je sur-interprète DDD "language-fluidity/naturalness requirement"? ou ... est-ce que je manque un concept? Je veux dire, devrais-je inventer un autre modèle de domaine, quelque chose, qui peut être un enfant de cluster et avoir interviewPlan associé?

Merci, Raka

---

Autres connexes: http://git.net/ml/programming.domain-driven-design/2006-06/msg00028.html

Answer 1

Je ne pense pas que ce soit trop tehnical. Les experts du domaine connaissent les mathématiques de base comme la somme et, dans ce cas, ils créent même ce tule.

impliquent des choses Tehnical invariants tehnical comme des tables, des index, des colonnes, des lignes, des identifiants, des fonctions, etc.