Is There a Symbiosis Between SOA and DDD?
With the increased popularity of SOA, taking a central stage in the enterprise architecture, it becomes more and more obvious that it has to start leveraging advances achieved by other related disciplines. This point of view is confirmed by an interesting discussion about relationships between SOA and Domain Driven Design.
While SOA is:
an architectural style promoting the concept of business-aligned enterprise service as the fundamental unit of designing, building and composing enterprise business solutions
a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains
The seeming commonalities between the two started this discussion (Trond-Eirik), by asking the following questions:
...what you are thinking about the concept of SOA vs.the concept of DDD? Are they a perfect match fulfilling each other? Are they exclusion concepts, meaning that if you use DDD you cannot use SOA? Are they solving/attaching different part of the problem domain? Are they solving the same part of the problem domain?
The reply from "moffdub" (user name) is that SOA and DDD are highly complementary:
DDD is a way to develop a deployment unit (single app). SOA is a way to glue together multiple deployment units.
A different approach to merging the two is proposed by Ashley Fernandes, who considers DDD as the technique for defining business services:
I correlate the service layer in 3D quite close to the WSDL services exposed by any UDDI. Due to this 3D and SOA co - exist quite well
Tomas Karlsson shares his practical experience in developing a DDD-SOA combination. He suggests starting from a pure DDD approach, then creating objects (POJOs or stateless beans) implementing domain objects and exposing them as services. As a result, he has created:
A service (or a set of services if you want) with a very clear responsibility: doing the back-end part of CRUD on a customer. Having such a service early will add stability early in the project.
According to Colin Jack, although a symbiosis between SOA and DDD is definitely possible, it has to be implemented very carefully. In particular he points out that the notion of entity service delivering, for example, customer information can be at odds with DDD.
My problem is that I don't see entity services fitting cleanly with DDD, even if you only expose those services for aggregates you've still got issues because your domain design is going to have to change and you've lost basic features like cross-aggregate transactions. I know you can loosen these things up, but if you do then are you really getting the benefits of SOA?
Casey Charlton sides with Ashley, considering that Tomas/Colin approach will lead to proliferation of very low granularity services:
...instead of taking SOA down to the lower levels I'm thinking that you are better to expose large services that each encapsulate entire domain models and then use messaging between these services. This is what SOA is when done properly ... any more granular level breaks the "coarse grained services" rule ... CRUD operations certainly have no place in an SOA architecture...
Casey’s opinion is supported by Andreas Ohlund, who quotes Bill Poole "DDD is for building the domain logic within coarse grained SOA services".
SOA and DDD are definitely supporting the same goal. Well designed services are the ones "whose name is familiar to the CEO or line of business owner, and the latter cares about what it does". Well designed domain objects, on the other hand, define a set of foundational objects that can be used for semantic data models, building services and passing information between them.
The symbiosis is key.
One thing seem for certain is that CRUD on entities is SOA done wrong.
Check out Nick Malik's blog on SOA and this post on DDD:
My own experience tells me that "tackling the complexity at the heart" can cause indigestion in SOA and vice versa - SOA's information model is anathema to DDD's model integrity.
I'd love for someone to comeup with a decent bridge though...
It's all in the layers
The right place for CRUD is at the Data Access level.
DDD helps define a clear API/language which is meaningful to the business, and this in itself is precious if you wish to organise and expose your application in a sensible way, SOA or not.
I believe that once you have only exposed the API of your Application Layer (or Service Layer as Martin Fowler calls it) to other systems, as a Web Service for example, you are on a good way to SOA and communicating in a clear way with external applications.
If you're still exposing objects via CRUD methods that way, then you have missed an essential bit in the middle which is called a Domain Layer.
CRUD has NOTHING to do with the domain.
Unless of course the domain experts explicitly work in a robotic "CRUD" fashion which I think is quite rare...or possibly the result of years of deformation by working with a poorly designed, user-unfriendly software solution =)
Re: It's all in the layers
- So, when you're saying "exposed the API of your Application Layer" what are the verbs if they are not CRUD?
- Perhaps they should be CRUD on some non-repository kind of service?
- What nouns does the Service/Application layer operate on if it's not you internal domain model?
- What nouns does the Webservice operate on?
- What makes your Webservice a SOA service?
Re: It's all in the layers
not everything that works is good. For example, you do not use plains to drive you to the airports while they can do it, right? This thread talks about SO and DDD concepts, your example is about specific technology. Plus, If you think that it is OK using REST from Web layer to reach databases, I can tell you that it is architecturally terribly wrong. None of applications I supervise may do so in spite of any business urgencies.
Web Service operates on nothing. It is just a more standardised interface. According to OASIS SOA standard(s), Web Services are not a mandatory part of SOA.
Answering your last question, let me refer to the article I wrote a couple years ago: soa.sys-con.com/node/219016
Just to clarify...
Just to be clear I was saying that SOA style put forward by Erl etc *is* at odds with DDD and so I'm against entity services. In fact I said:
"So instead of taking SOA down to the lower levels I'm thinking that you are better to expose large services that each encapsulate entire domain models and then use messaging between these services"
So I'm not saying I want granular services, I'm saying avoid them and instead consider your top-level autonomous services surrouding bounded contexts, which is exactly what Casey and Andreas were saying. So I think we were all in agreement.
We use such approach
The whole platform is componentized into domain components. Every domain component has domain layer, where domain objects are implemented (entities, services, repositories, etc.).
The domain objects are exposed to domain layers of the other domain components only via facades, which translate domain objects into DTOs.
To the outer world facades are exposed via REST layer.
Besides facades, there are two additional integration patterns between domain components:
1) extension points - extensions (see Eclipse platform), but implemented in a way that extensions can be remote
2) domain events subscription (planned for future)