New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Is There a Symbiosis Between SOA and DDD?
Posted by Boris Lublinsky on Sep 15, 2008
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.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
The symbiosis is key.
by
Naeem Ismail
Posted
What's SOA?
by
Eugene Tolmachev
Posted
It's all in the layers
by
Valery Derongs
Posted
Re: It's all in the layers
by
Eugene Tolmachev
Posted
Re: It's all in the layers
by
Michael Poulin
Posted
Just to clarify...
by
Colin Jack
Posted
-
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.
-
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:
blogs.msdn.com/nickmalik/archive/2008/09/03/app...
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... -
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 =) -
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? -
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: soa.sys-con.com/node/219016 -
@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.
6 comments
Watch Thread Reply