There has been a lot of discussions on how the ECDM relates to SOA services and their DDD domain objects, and how the BPM process layer relates to the SOA process layer. In the following ontology I have tried to model the relationships between ECDM and domain objects, Shy Cohen’s service taxonomy & ontology, and Jean-Jacques Dubray’s SOA+BPM ontology. Click to enlarge the ontology:
Note how there are processes at two levels in the model: the event-driven resource lifecycle processes for domain objects, and the human-driven business processes that utilize the composed services. The ECDM is applied at the service composition and human workflow level, while the services operate on the domain objects to manage the lifecycle of these resources in accordance with the business events. These two levels are separate DDD bounded contexts with well defined mappings between them: the business process domain and the resource lifecycle domain.
Note that the ECDM is related to, and is a subset of/reference to, the resource domain objects (CIM); like a mail order paper form that contains e.g. some customer data and references to product data. The word "subset" is central, e.g. the “customer has moved” action event has a ECDM document that contains the data pertinent to that specific business process event, not the complete schema of the customer domain object. The resource process service used to act on the “customer has moved” event does of course operate on the actual domain object, but this is invisible to the human workflow process.
The figure also shows business events and processes using two-headed lightning arrows to signify that these are separate model artifacts and not to be considered integral parts of service processes or compositions. I am a strong believer in designing a service-oriented solution by applying "EDA style" thinking to avoid missing out on the events and their documents due to traditional “invoke operations” SOA thinking.
An aspect not shown in the model is that the need for agility increases towards the top, while the cost of change increases towards the bottom. This is an important argument for having processes at two levels; it allows you to contain the frequent changes to the human workflow processes (mashup style compositions) and composite services rather than having to constantly make changes to the core resource level services, which could become very costly as the number of service subscribers increases over time. This is something that your business people should readily appreciate.
Design your system to have flexibility in the business processes, not in the composed business logic. The diamonds of your business process are the business decisions, and this is where you should implement a business rules engine (BRE) mechanism. Process flow logic is not business logic.
Finally, the model show how claims relate to services at all levels. I have done this to show how a claims-based security model is a cross-cutting concern throughout a service-oriented solution. I strongly recommend designing in process claims right from the beginning, as this makes it easier to learn how access control relates to the business processes and solution domain.
Master Data Management (MDM) relates to the "Resources" in the above ontology. It is imperative that you apply a MDM strategy to your enterprise resource domain objects to avoid inconsistencies and multiple versions of the truth.
I hope this ontology makes my viewpoint on SOA+BPM+CDM clear to you. Feel free to comment on this model, and also check out the six figures in JJD’s ontology for models showing different perspectives of resource lifecycles & business events, BPEL, BPMN and human tasks.
See also this related post.
