OOD vs SOA Approach to SOA Domain Modeling

An interesting debate on Gervas Douglas's SOA distribution list ensued between the OO and SOA camps of thought that spanned domain model, message format and service design considerations. The debate concluded with a few rules of thumb that can be applied for a majority of SOA scenarios:

• A service oriented modeling technique such as DOSOM(Domain oriented service modeling) is the first step in the identification of a candidate list of business services with clearly separated domains based on a functional structure of the business
• OOD is ideal for designing the internals of a service once the business contract is defined
  
• Minimize the amount of information to be exchanged between services through the definition of a minimum canonical model using MDM (Master Data Management) techniques

The entire discussion around domain modeling was initiated by Kirstan Vandersluis when he asked the group for general guidance around standardizing message formats within an enterprise based on three approaches he is considering

1. Base the internal message format on the external message standard (MISMO for this industry). This message set is bloated, but is mature, supports most areas of the business, and is extensible for attributes specific to this company and its processes.
2. Create an XML-based message set based on the company's enterprise data model, which the company has invested a great amount of money into, and includes a very high percentage of all attributes needed in the business. In a nutshell,we've generated an XML Schema from ER Studio, and will tinker with that construct types that define the payloads for messages.
3. Use MISMO mainly for its entity definitions, but simplify the structure to improve usability. We benefit from the common vocabulary, but would ultimately define dozens of transactions over the coming years that MISMO has already defined.

 Steve Jones responded with three observations based on his experiences with SOA information modeling

• Industry standards such as MISMO are suitable for communicating with external partners within the same industry
• A canonical model is a good fit for internal usage only in the rare case when the communication scenarios rarely change and the entities are not shared across business domains
• In a majority of the intra-enterprise usecases the requirement is to design for flexibility and change which translates to sharing entities through MDM and maintaining a minimum canonical model. This also avoids the pitfalls of extending industry standards to accomodate communications with domains outside of an industry standard that exist within an enterprise, for e.g. HR.

Ashraf Gulal shared his experiences from an OOD point of view:

Domain data is the classes that encapsulate information needed to implement services.This uses the classic object/relational mapping.

to which Steve Jones responded with:

Object/Relational mapping has nothing at all to do with semantics or SOA and is a little bit random here as is the phrase "Domain data is the classes that encapsulate information needed to implement services". Data and classes are different beasts, one is a structural element (class) the other is an instance (data).

David Tildesley supported Ashraf Gulal's OOD approach with:

I find myself agreeing with Ashraf in his advocation of using basic OO design principles (encapsulation, loose coupling, favour composition over inheritance etc) concepts in applying these to SOA. It is the abandonment of these principles that leads not only SOA projects but also application development down the rocky road to failure and a mire of confusion.

I would recommend following Coad, De Luca etc. advice and use the four color modelling archetype objects and the archetype domain shape (ADS) (a.k.a domain neutral component) which is proven technique/pattern. The ADS will indicate to you, the logical components (a group of classes) that are loosely coupled that become your "entity" services and these components become your "business components" and from there it is straight forward engineering to get your xsd's (avoid xsd restrictions and make everything optional and package appropriately using imports and includes). Your SOA messages are views on the CDM and contain business components(s) and additional metadata/context for the SOA infrastructure purpose. Each business component will have at it's heart a core entity (a pink or a green). The decoupling points will be at the roles (yellow).

To pitch SOA (an approach with some guiding principles) against OOD  doesn't appear to me to be useful - it's somewhat akin to comparing a UI layer against "OO" in a traditional 3 layer application architecture. SOA practitioners are free to use OO design practice, patterns and techniques to help them them arrive at the CDM and candidate list of services or not.

Both Michael Poulin and Steve Jones disagreed with this approach to candidate service identification and domain modeling. Some highlights from Michael Poulin's response:

SOA is functional model, not object model; it is that simple. As such, the model requires certain caution when designing things because function much closer to the human behavior and carries some aspects of it that are not present in technology-centric OO.

When you approach to container design, the first step is not OO or DDD; the first step is DOSOM and only then OO/DDD

Steve Jones summarized:

I'd advocate using an SOA approach for services to create clearly separate domains, then create a minimal canonical model that uses techniques such as MDM to minimise the amount of information required to be exchanged.  On single application spaces where the services have a high dependency and high cohesion then a more OO centric approach for the delivery of the infrastructure of those multiple services can, and does work, but as you look to span multiple business domains and organisations it ceases to be viable.

SOA for the business architecture, OO for the implementation of service specifications and an information interaction model based on minimum information exchange rather than CDM.

David Tildesley summarized the MDM side of the discussion with a usecase which Steve Jones verified as a legitimate usecase for MDM:

Would it be fair to say that MDM is about creating an "XREF" to facilitate a single view of customer - only needed when you have multiple applications (most often in differing linesof business) all with their own view of customer. MDM tells us whether "Thomas J. Smith" in system A is that same person as "Tom Smith" in system B and holds the foreign key references to the entities in each application.