I've recently been delving into DDD resources (books--Vaughn Vernon's--and other online resources) and in my attempt to do two things at once (work on a pet project and apply what I've been learning) I found myself stuck at a point where I have to make a decision about how aggregates and entities are created, while maintaining invariants and not break the rule about transactional consistency for one aggregate at a time.

Domain representation

In my domain I can have an aggregate root that we can call Container, which contains some metadata properties and a list of ids for referencing another aggregate, let's call this one 'Document'. Both of these will be editable independently of eachother, so it makes sense to have them as separate aggregates. To change the Document I don't have to update the Container and vice-versa.

For me, an empty Container does not make sense. When you create it, there needs to be at least one Document in it. I was thinking of providing it by default.

Having this rule means that when I create a new Container in order for it to be in a valid state, it needs at least one Document id. To create a Document you need to assign it its parent id, the Container. So now I feel I have chicken and egg problem.

Things I've considered

I could get a new id from the Container repository and create that child Document with it as its parent, then create a Container with the same id and pass the Document id as a "child". This would be done within a DomainService method, which is what some recommend to maintain consistency between multiple aggregates. This feels like braking the rule of "one aggregate" at a time.

I could create a new Container, publish an event that it was created, then a subscriber would create a "default" Document and assign it to the Container. This seems like a good way of doing it, but if the second event is not properly handed I end up with an empty/invalid-state `Container.

Do I treat the Container as a kind of a tag and not make it an aggregate? basically flipping the whole thing over? A Document then would be center stage, so when I create a Document I need to assign/create a ContainerId (tag)... Listing would then be a bit more cumbersome, since you'd have to keep track of all ContainerId form all Documents.

To make matters worse, a Document can have referential ids for other entities (I'm still deciding if it's worth making those value objects, even though it feels to me like they have life-cycle--can get updated over time), which also has this rule of "at least one".

Any suggestions? Am I modelling this wrong? Are my concerns valid, but shouldn't pose a problem in this particular case? Any help would be much appreciated!

I have so many questions! but I'll stop here.

Visual aid

enter image description here

  • I don't see any questions in here which are answerable by anyone on this site. All of this really depends upon your requirements, indeed DDD fundamentally relies upon having a fairly comprehensive analysis of your requirements so any such questions fundamentally cannot be answered in any useful nor meaningful way by anyone who doesn't already have a firm grasp of the particular domain you're working in. Jun 23 at 8:02
  • I'd suggest simply making decisions based on whatever your current understanding is right now (revisiting any requirements you're unsure of for further analysis if possible) and try them to see how they work out; if your requirements change or your understanding changes, then you can update your domain model accordingly. Jun 23 at 8:05
  • Thank you for your comments @BenCottrell! I guess I was looking more for guidance in terms of “when in doubt, do this” for DDD practices specifically, but I do understand what you’re saying.
    – 0vidiu
    Jun 23 at 17:30


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.