Command processing a quite often is just about editing entities or aggregates, along with the other side effects it might have. There are two distinct styles of processing such command.
Decoupled domain model nudges the implementation towards to the edit approach and without it one tends more towards to overwrite approach. Overwrite approach when domain model is not decoupled is appealing for it requires less code, but this has significant downsides. Irrespective of whether we decouple the domain model, one can still use either of the approaches. Lets look at how both of them work.
Overwrite
<<Sample Code>>
Here we looked at a sample implementation of overwrite approach. We would not try to discuss this in too much detail as this is fraught with problems. It starts breaking down because the request doesn't carry the complete state of entity/aggregate being changed. This is generally patched in following ways leading to undesirable consequences.
a) Command request data is constructed from the query operation performed beforehand to fetch the same. Therefore in order to have complete state of entity in the command request, one needs to query the complete state, even though not everything is edited by the user. This creates unnecessary load on the database. If domain model is decoupled then every time entity definition changes one need to revisit this implementation to make those changes. This is error prone when new fields are added to the entity.
b) The missing parts of entity to be saved is filled up by loading the data from repository during command processing. Like the previous approach one needs to revisit such operation whenever the entity definition changes, else causing undesired behavior.
When using hibernate this approach causes performance issues during the save causing the update of the entire object tree even though only parts of it might have changed. Also, it can become quite tricky if one needs to compare the existing state of entity against the new state.
Edit
<<Sample Code>>
Edit domain model first loads the existing state of domain objects from the repository, changes it by applying the command data onto it, invokes domain operation and then ask repository to save the domain objects' state. This style of command processing can thought of as two phased approach. In the first phase we resurrect domain layer based on the command and edit it with new values. In the second, domain logic execution phase, the domain layer executes the follow up operations on domain model. The first phase is executed in the application layer and second triggered into the domain layer. This break up helps in separating the domain logic from the data retrieval and mapping.
Domain memento
There would be scenarios where the previous state of entities are also required during the domain logic execution. The previous state might have been overwritten during resurrection of domain layer. Domain mementos are created before the entities are edited with the new values. Domain service demand the required mementos objects in its API which is satisfied by application layer.
<<Sample Code>>