0

I am modeling an inventory application where items are managed and grouped into a containers and assign one unique number which will identify the inventory instance and can easily manage using RF IDs in warehouse. In these scenarios a container can hold another container or more which will point to parent container to form a hierarchical order or parent child relationship. So my question is If I model container as an AggregateRoot with a collection of child Containers by reference, will it break the DDD rule. The reason for treating this way due to the transaction boundary where I can adjust the inventory movement or manage quantities when a child container is moved or added into Parent container by using parent RF ID scan. Here is my sample code

public class Container:AggregateRoot
{
public virtual string Id{get;protected set;}
public virtual ScanId {get;protected set;}

public List<Container> ChildContainers {get;set;}

public void Detach(Container containerToAttach){

//Todo Adjustments
ChildContainers .Remove(containerToAttach);
}
public void Attach(Container containerToAttach){

//Todo Adjustments
ChildContainers .Add(containerToAttach);
}
}
biju
  • 1

1 Answers1

0

If you are really dealing with physical warehouses, then you'll want to hear at least one of Greg Young's discussions about how DDD works in that domain.

Short version: the real world is the book of record; your database just has cached copies of that information. You don't reject messages that describe the real world to you, but instead accept that new information (assuming the source is reliable) and issue escalation reports if your data indicates that some "invariant" has been violated.

OK, to your question

  1. No, there isn't anything against the rules about the representation of one aggregate root including an identifier of a different aggregate root of the same type.

  2. Hierarchy can be difficult, especially if you are worried about being able to track things like "uniqueness". It may turn out to be more useful to have the child container include a copy of its parent's identifier, rather than having parents with lists of children.

  3. Often, our aggregates are not centered on nouns in our domain, but instead upon processes about the nouns in our domain. Trying to pile all of the information into a single "The Thing" aggregate is a common flavor of mistake, so be careful not to accidentally repeat that error.

  4. As you try to decide where your consistency boundaries belong, keep in mind that the information you are getting from the real world is probably a nanosecond old by the time it reaches your domain model. Trying to model history as something that is under your control is another common flavor of mistake.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
  • Could you expand on point #3, perhaps with an example? Do you mean that the same bits of data may be part of different ARs modeled around use cases? Roughly speaking, if there's a use case to update A & B on their own, but also A, B & C together, you'd possibly have ARs `A`, `B` and `ABC`? ARs would basically be locks around data, but would not "own" data. – plalx Jun 24 '20 at 04:04
  • @VoiceOfUnreason point#1. I am intending to reference whole child ARs instead by referencing by ID. Do you think this is a bad design? – biju Jun 24 '20 at 12:21
  • Short answer: probably."An aggregate is a cluster of associated objects that we treat as a unit for data changes". When objects belong to multiple clusters, then ensuring correct data changes becomes more challenging. You'll want to look for discussions about "consistency boundary" and "transaction boundary" to get a feel for the kinds of problems that appeared. – VoiceOfUnreason Jun 24 '20 at 14:16