In a world of rapid development, minimum viable products, and mobile applications Domain-driven Design (DDD) has established itself as a go-to design paradigm. However, DDD’s problem focused multiple-model (and even multiple source of truth) approach is quite at odds with the notion of a Canonical Data Model (also known as Common Data Model or CDM) which has been a staple of SOA best practice.
Adopting DDD in a SOA project is both liberating and vexing.
Liberating because developing a common model is one of the most trying parts of the traditional process; if you have ever been in a CDM workshop with many, sometimes competing, business units you will understand what I mean. There are also, maybe unsurprisingly, strong synergies between SOA’s task or business service layer and DDD. Being able to focus on one business domain at a time leads to a very natural service definition and desirable service qualities like abstraction, autonomy, and clarity of purpose are inherit in services defined from a domain driven paradigm.
On the other hand we must ask: without a common model how do we achieve key SOA goals like reusability, standardisation and loose coupling?
Before answering let me first ask how often are these goals achieved? Or maybe more importantly when they are achieved how often do they deliver significant benefit? A new service might occasionally leverage existing services but I’ve yet to see a significant component replaced without a major overhaul to, or outright replacement of, the services supporting it. Technology and business move too rapidly.
Using DDD with SOA is not about sacrificing reusability, standardisation and loose coupling but about recognising that investing significant design and development effort in complex (and aesthetically pleasing) abstractions rarely delivers the best bang for buck.
So how can we achieve these goals in a SOA based on DDD:
- Drive integrations from events. If every happening in the business raises an event it becomes very easy to add new responses to business events. By defining the event in the language of the business domain where it happened we get a natural and complete definition of the event. This helps us ensure we are responding to what is really happening in the business.
- Provide micro services which deliver laser focused reusable value where it is needed. The key part here is ‘where it is needed’. Traditional SOA tends to make everything a service, overcomplicating designs and creating work which doesn’t add value. DDD doesn’t preclude the need for utility services or other shared services, it just helps us determine when we need them.
- Don’t be zealous. Some standardisation is okay, if nine out of ten business units use a common customer record it might be worth strong arming the tenth in to conformance. CRUD style Entity services are okay if thats how the entity behaves: unless we run a delivery company we probably don’t have much domain specific information about a postal address.
Although on the surface SOA and DDD appear, if not opposing, at least orthogonal, with the right approach they can not only work together but provide a paradigm that can propel your SOA implementation forward.
