Say we have a domain entity that requires collaboration, for example a ConstructionProject (CP). It's created and owned by a Company, they specify parameters and then invite an Architect and one or many Contractors.
It's clear that ConstructionProject will have states. DDD tells us that good thinking about states must tie them back to operations, initiated either by actors in the system or time (some deadline date arrives etc.).
So, naively, we have CreateConstructionProject operation that produces a CP in draft state. Company fills the draft CP out over time and at some point they're ready to progress to some next stage, maybe to seeking_building_permissions via ConstructionProjectSeeksBuildingPermisions operation.
But say the company wants to make amendments to the CP once it's started seeking building permissions, changes that would not affect the parameters of land needed etc.?
A bad design would introduce a new state editing and write logic to disambiguate the data in this editing state VS a previous non-editing state, making editing a ghost state.
A better approach is to take inspiration from Git and treat any edits as a "feature branch" of the real CP, which remains in seeking_building_permissions state. Once edits are complete and ready to be applied, call ApplyEditsToConstructionProject operation which applies edits. CP has never exited seeking_building_permissions state and no special handling looking up previous non-editing state has been needed.
KISS
Top comments (0)