While it is true that a picture is worth a 1000 words, it does help to have an associated detailed description to go with a diagram like the one on the front page of Refactoring, and I have not found it on this site (perhaps I missed it?). Since this diagram exists, I assume that there has been significant internal discussions on how it will work and why it is the best approach. Can you provide better detail on how the refactored system will work? For example, I see that you have an Event Driver common service:
- Does this event driver exist today?
- Is this a simple event mechanism or more akin to something like JMS that can support multiple types of queues? Guaranteed delivery?
- Why was this chosen as an ancillary piece rather than the single mechanism of package-to-package interaction (event driven architecture)? I am assuming this is an ancillary piece, because it is not the gateway to the API.
Why is common data access its own box? It would seem to me that the only common data access is the functionality in the DB Access box. All other commonly used information should be surrounded by its own API. I realize that this isn't there today and won't be there for this single package refactoring, but this information should be accessed throught a stubed API of its own so as to avoid refactoring the refactored code, shouldn't it?
What will the APIs look like? Is there a standard format? Is there any plans for auditing and/or security code in the API layer? How will API changes be made and managed over time? Will there be multiple versions of an API in the code base at a single time?