This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: DDD the opposite of SOA? Uh, no.
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Just recently the .Net Rocks crew interviewedJimmy Nilsson on Domain Driven Design (DDD). In the first half, Richard Campbell describes SOA as the opposite of DDD, where SOA "very much is a set of technologies, that are going around trying to find a problem to solve", and DDD is based on focusing on the problem and designing a solution for that problem.
Despite my high regard for Richard, I must say that he missed the boat on this one. Maybe the only thing that has achieved industry-wide agreement in terms of SOA is that it is NOT a technology.
As for the relationship between DDD and SOA, they are not opposites. It would be more appropriate to say that they are orthogonal. You can employ DDD on an application without SOA, and conversely you could employ SOA without DDD. Although I believe that many principles of service-orientation are applicable in most distributed systems, I feel that DDD has much broader applicability and would suggest training your staff in DDD before going to SOA.
As for the question "where would you see DDD in a service-oriented solution?" Well, my answer would be that the domain model would be nicely encapsulated by a single service. The activities exposed by the domain model could also impact the message-exchange patterns that the service supports, although sometimes higher level constructs are needed. Paul Gielens' last post on the subject, as well as a bit of the discussion on an eariler post shows just how trivial it ISN'T :)
Previous Topic
