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
DDD is:
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.