How can changes to domain model objects be saved independently from the domain model?
You are developing a multi-user application that commits transactions on an application server. There are several reasons why you might want to be able to replay a user's business transaction after aborting a server transaction:
If a transaction fails, you need to abort the transaction to get a clean view of the repository. However, rather than losing the user's changes, you would like to be able to attempt the transaction again.
For long business transactions, it may be desirable to change persistent objects while outside of a server transaction. However, changes to persistent objects can only be saved in the repository while in a transaction. Therefore, you might want to allow the user to modify an object outside of a transaction, then replay the changes inside of a transaction.
Save the sequence of messages that can be sent to cause the desired changes to occur.
A transaction specification represents a sequence of changes to server objects. These change specifications are maintained independent of the target objects, so that the changes can be preserved after the application server aborts a transaction, rolling back the view of the repository to a previous state. The changes can then be replayed in a new transaction.
As a result of adopting this solution, the developer must decide how to keep a record of changes in a business transaction. Aspect Change Specification records the sequence of messages that must be sent in order to cause the desired changes. After an abort, the messages can be sent again, in order to redo the desired changes.
This solution is relatively easy to implement, although it requires explicit code in the client application to record the messages sent to domain objects.
The solution does not involve any copying. Therefore, it does not introduce a large number of extra temporary objects into the environment. It also means that references between objects are maintained with no extra effort.
By recording the sequence of messages, business rules that are triggered by setter methods will reapply in the correct sequence whenever the transaction is replayed.
Aspect Change Specification is a way to record user-initiated changes to domain objects which may be replayed.
Dirty Object Pool is an alternative to this Transaction Specification solution. It is another way to record changes to domain objects, so that changes can be copied into a new transaction.
Last Commit Wins and Merge Conflicting Updates provide specific strategies for replaying changes.