How can a client application record a change to a domain model object independently from that object?
You are developing a client application and you want to record changes to server objects in a transaction specification, so that the changes can be preserved across transaction boundaries. For example, you might want to replay changes after aborting a transaction.
Specify the message that must be sent in order to accomplish the desired change. A message is completely specified by its receiver, method signature, and arguments.
As a result of adopting this solution, the client application is able to replay changes across transaction boundaries. Therefore after an abort, the messages can be sent again, in order to redo the desired changes. This solution also supports a conversational transaction model in which the change specification is built outside of a transaction and then replayed inside of a transaction to cause the changes to be persistent.
Flexibility is achieved by maintaining an independent specification of changes from the results of the changes themselves. By providing a specification, rather than just recording the results, it is possible to reuse the specification across transaction boundaries, so that the end user is not required to reenter data.
Dirty Object Pool is an alternative to this Aspect Change 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.