Is There a Symbiosis Between SOA and DDD?

Posted by Boris Lublinsky on Sep 15, 2008 08:04 PM

Community

SOA

Topics

Design

Tags

Service Design ,

Domain Driven Design ,

Domain Modeling

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.

1. Back to top

   The symbiosis is key.

   Sep 16, 2008 9:50 AM by Naeem Ismail

   Just to support the summary of this article I thought I would offer my tuppence worth. DDD is concerned with "tackling the complexity" of the "foundational objects" while also providing a ubiquitous language to bridge the gap between all stakeholders. SOA joins DDD to support the business through coarse-grained services necessary to deliver the ROI longer term... However, the points raised by Colin should not be overlooked such as cross aggregate transactions. I would say there's definately advantages to DDD and SOA collaboration but we need to find the balance between them to deliver what the business needs as there are elements of both that overlap in the real world.

   Reply

2. Back to top

   What's SOA?

   Sep 22, 2008 1:36 PM by Eugene Tolmachev

   If you are going to correlate the two then you better come up with definitive description and goals of SOA, which unlike DDD are, I believe, largerly up to the interpretation. 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: http://blogs.msdn.com/nickmalik/archive/2008/09/03/applying-ddd-to-it-management-first-failure.aspx 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...

   Reply

3. Back to top

   It's all in the layers

   Sep 23, 2008 4:17 AM by Valery Derongs

   I was shocked to see CRUD discussed in a SOA/DDD discussion! 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 =)

   Reply

4. Back to top

   Re: It's all in the layers

   Sep 23, 2008 3:47 PM by Eugene Tolmachev

   I'm going to play devil's advocate here for a sec and say: REST+HTTP is CRUD. And it works perfectly.
   - 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?

   Reply

5. Back to top

   Re: It's all in the layers

   Nov 20, 2008 6:56 AM by Michael Poulin

   To Eugene Tolmachev: 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: http://soa.sys-con.com/node/219016

   Reply

6. Back to top

   Just to clarify...

   Feb 27, 2009 8:40 AM by Colin Jack

   @Boris 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.

   Reply

• Older >