I've looked at 2 other questions that seem related:
- Is Aggregate Root with Deep Hierarchy appropriate in DDD?
- How to define DDD Aggregate root for hierarchical data structure?
However they're not exactly the same as my situation; maybe missing the "constraint" aspect.
My situation: I have an AR named "Study", and a Study can be organized by cluster (borrowing from clustered-sampling concept in survey domain).
Let's say this "Study" takes this parameter "clusteringDepth" (an integer) in is constructor. Let's say: I specify 3 (provinces, counties, cities).
That's just a spec. of a Study. When you actually conduct a study, you create an instance of StudyPlan based on the Study.
So, in this case I will have an instance of StudyPlan that has a list of provinces (first-level clusters). Each province, has a list of counties (second-level clusters), and each county has list of cities (third / final-level clusters).
On each cluster you can attach quota information, and date range (specifying how many interviews you have to raise in that cluster, and the date interval for the interviews). Obviously a parent cluster must maintain invariants like "sum of quotas of child clusters must be less or equal to the quota of this cluster".
Ok..., now, the constraint: you can plan an interview with a respondent. For that you'd create an instance of InterviewPlan. But..., this interviewplan can only be attached to terminal (third-level) clusters.
Of course, it's easy to implement that constraint (e.g.: in the addInterviewPlan method of a cluster, I'd check if the cluster has a parent or no).
But..., for some reason... I think this is not a good DDD design. That constraint sounds too technical; it doesn't go naturally in a normal domain conversation.
My question: am I over-interpreting DDD "language-fluidity/naturalness requirement"? or... am I missing a concept? I mean, should I invent another domain model, something, that can be a child of cluster and have associated interviewPlan?
Thanks, Raka
Other related: http://git.net/ml/programming.domain-driven-design/2006-06/msg00028.html