Lets say, for example, I have a widget ordering application. It allows customers to order from a catalog of widgets. Obvious object choices might be 'Catalog' and 'Orders'. The 'Catalog' object will allow me to browse, add and delete widgets. The 'Orders' object will allow me to create and update orders.
They are both multi-thread safe and handle object locking and database transactions internally. They are nicely encapsulated/compartmentalized -- until a requirement comes along that says when a widget is deleted from the catalog, line items containing that widget must be deleted from existing orders.
A common way to handle this scenario is with the observer pattern. In other words, an event is raised from 'Catalog' when part is deleted. A mediator then handles this event and tells 'Orders' to remove line items with that widget.
The pros: preserves encapsulation, loose coupling.
The cons: are not the removal of the part and the update of the orders a single, atomic operation? This technique would violate that. In other words, if an error happens handling the event, the part may be removed without ever updating any orders.
I am favoring the cons. However, this can only mean that another object is required -- one that aggregates 'Catalog' and 'Orders', and causes both operations to be performed atomically. The problem is each object performs object locking and database transactions, neither of which I can see how to cleanly extract -- ie, technically the new object should handle that responsibility now because you cannot lock objects and perform transactions twice and still have an atomic operation.
Thoughts? Is this a classic problem I've not seen before? I've been down the Spring road but I don't think there's anything AOP can do here.
Thanks.
