Reputation: 6845
Here is the problem I am trying to solve. I have CLIENT. That CLIENT needs software to manage INCIDENTS.
The CLIENT has multiple FACILITIES. Each FACILITY contains multiple LOCATIONS.
When they log an INCIDENT, the minimum info they need to log is the LOCATION where it happened, the FACILITY for LOCATION where it happened and WHAT happened.
So I have questions are modelling this problem. This is what I have.
Here is my question: I this a good design. The FACILITY root makes sense imo, because a LOCATION cannot exist on its own. But Incident now holds a soft reference to both FACILITY and LOCATION.
I considered making LOCATION a value object instead of entity. I this case INCIDENT would have its own copy of LOCATION. But this becomes a problem if LOCATION mutates.
Any ideas? Thanks in advance. Maybe I am missing something. Just for the record - INCIDENTS as they contains workflow etc become very complicated and is the core domain. Maybe only INCIDENT should be solved with DDD?
Upvotes: 1
Views: 1410
Reputation: 43728
Well, if the location changes are you sure you want the changes to propagate to the incident's location as well? I guess the only reason for it to change would be fixing typos, but that's a question you need to ask.
In any case, you can reference the composite ID, which I would most represent as an IncidentLocation
value object. The rule only states that you can't have an object reference to the child entity and that you can't only reference the child entity's ID given it's only guaranteed to be unique within it's root.
Please note that it may be a good idea to have at least two contexts here. A CRUD-based context where facilities and such details would be managed and an incident logging context where the incident's lifecycle could be managed. In that case Location
could be an entity in the first context and an immutable value object Location {facilityId, locationId}
in the second context.
Upvotes: 4