To be able to efficiently compose the services, a model that ensures shared sematics is needed, and in my last post I described the business event canonical domain model (ECDM). David Chappell calls this approach semantic data integration. ECDM is a similar concept to the EAI canonical data model [Hohpe/Woolf CDM pattern (355)], but it is a model with a slightly different purpose at a different architectual layer and it is not just about the data. The ECDM is about the events, messages and data passed between services, not about having a unified superset of the entities within an enterprise.
The ECDM allows for composition of services without having to know and comply with the model of the underlying service logic, all you need to know is the message types. This is a big advantage, and allows for the consumers to be isolated from the details of the entity services. E.g. all a service consumer need to know is the "AddressChange" data of the "CustomerHasMoved" event, not the complete data schema of the "Customer" entity service. ECDM is closely related to the Common Information Model (CIM) concept. Note that the ECDM message types are projected compositions of the referenced CIM resources - not just simple compositions of resource objects.
The term 'domain' is borrowed from Domain Driven Design (DDD). Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. Read stories about how DDD can be applied to a diverse set of architectual problems: Practitioner Experience Reports
Focusing on the bounded context for modeling the flow, events, messages, data and semantics involved in implementing the core business processes of the domain, should make it easier to come up with a working model. Note again that the ECDM is about more than just the data. Hence the term canonical domain model. Arvindra Sehmi and Beat Schwegler used the same term in Service-Oriented Modeling for Connected Systems, an article that also provides details about creating a service model.
Partner/ 3rd party/ outsourced services are not part of the core business domain according to DDD. If they were core processes in your business, how come they are so general that they can be outsourced or bought? Core processes are those that make your business unique and give you a competitive edge. DDD dictates using translators or an "anti-corruption layer" against services/systems that are not within the domain.
Having a canonical schema model at the entity service layer might be feasible within an enterprise, but should be avoided as this will cause very tight coupling to the One True Schema. Making every entity service depend on the One True Schema will make it impossible for the services to evolve separately, they will no longer be autonomous. If agility at the entity service layer is less important for you, then such a service straight-jacket might initially feel good. Trying to make a enterprise data model (EDM) is not a good idea for the same reasons. Steve Jones has a good post about canonical form issues and how you cannot enforce your model upon the world: Single Canonical Form - not for SOA
Federated ECDM
DDD recommends splitting big, diverse and complex solutions into several bounded contexts. Set explicit boundaries based on e.g. orgranizational units and application usage. A natural boundary in SOA is partner/ 3rd party/ outsourced services. Each set of services that is not under your control and that you cannot enforce your ECDM upon, is a separate bounded context (domain model).
Note that within your enterprise service model there will be several other bounded contexts for different domains, afterall ECDM is the canonical model across all the services in your enterprise.
You should identify each model in play on the project and make a context map. A context map describes the points of contact between the domain models, in addition to outlining explicit translation for any communication between the models.
This figure show how a context map is used to show how two domains relate to each other:
The figure and the definitions of "bounded context" and "context map" is taken from the 'Strategic Design' chapter of the book "DOMAIN-DRIVEN DESIGN" by Eric Evans [Addison-Wesley, 2004].Note how not all elements of a domain model needs to be mapped to other models. Only the interconnected parts needs to have a translation map. E.g. the credit check process is provided by a 3rd party, thus it exists in a separate external ECDM. Your ECDM needs to have a translation map to the other service to be able to invoke it. Note how similar this is to the purpose of the ECDM itself: translating between business process compositions and the underlying, composed services. Thus, the context map is the basis for modelling a Federated ECDM. A federated ECDM serves the same purpose as the ECDM, just between multiple enterprise service models instead of within a single service model.
