An Interest In:
Web News this Week
- April 24, 2024
- April 23, 2024
- April 22, 2024
- April 21, 2024
- April 20, 2024
- April 19, 2024
- April 18, 2024
Editing is not a state
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
Original Link: https://dev.to/epigene/editing-is-not-a-state-55m9
Dev To
An online community for sharing and discovering great ideas, having debates, and making friendsMore About this Source Visit Dev To