Refactoring Diagram

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?

 

Rob Sax

like0

Comments

Diagram discussion

Kathleen Keating's picture

There has not been much discussion on this diagram.  We discussed it internally, but the idea was to put together something quick, generate some interest on the project, and get input from open source community.  Also, not everything has been decided yet on the architecture front by the Architecture Team, and what we do here does have some dependence on them.  We believe they are shooting for mid-December for the first complete version of their SDK.  Any discussion to make the diagram better in particular and have ideas what exactly to do for refactoring is certainly welcome.

In the diagram in particular, "Event Driver" is meant to be a simple event mechanism to replace direct calls from one package to another that currently exists in the code. What we are trying to do here is replace direct coupling by configurable "listener" Mumps tags.  In fact, the first implementation of this will likely be storing the current calls as data for the source package: this removes direct coupling between packages so that the source package does not need to know about where it is calling -- it will simply retrieve the data and call whatever is in the data.  That is a step in the direction of plug-in packages; it is also a step towards more complicated messaging schemes that the Architecture Team will decide on.

Per our understanding of the architecture, there will be some centrally stored patient, patient encounter, and provider data that will be accessible nationally.  This data may be cached locally, but at any rate the methods to get this data will be different from getting data from the local database to a specific package.  In addition, the methods to get this central information are likely to be the same for all packages; we have a separate Data Access box to differentiate between these two sources of data.

Any standards and how APIs changes will be made and managed over time is in the Architecture Team's domain and we are sure they want to hear any ideas and suggestions. For this project we will try to follow their guidance and to define the APIs in the Mumps domain.  We expect that this may require some Mumps API standards to be defined, but this has not been worked out yet.

like0