DDD and SOA Are Unrelated

There seems to be a lot of discussion these days regarding the relationship between DDD (Domain Driven Design) and SOA (Service Oriented Architecture).

Udi Dahan says they are orthogonal, and via that post, Richard Campbell says they are opposites.

My answer is that they are unrelated.

DDD relates to the implementation of a Service.  How a Service is implemented within a SOA is unimportant, and the adoption of DDD is just an implementation detail.  The Service may be implemented in any manner - as a procedural script, functional program or as object-oriented code - in Logo, Perl, RPG or C# - who cares?

That being said, one thing I advocate is that a Service is not equivalent to an Application.  A single Application may be distributed, and itself consist of a number of Services that communicate through messaging across AppDomain or process boundaries.  Perhaps that is where most confusion lies.


  • The only difference between orthogonal and "totally unrelated", in my opinion, is that orthogonal "things" have an intersection point - you yourself said it; DDD can be used to implement a service.

    As to your point about "applications", I'd have to say that seeing as the terms "service" and "component" are ill defined, "application" shouldn't be much different.

    Personally, I object to the term "distributed application" in that it blurs boundaries that are important. For example, databases are often considered to be inside a distributed application, however they are also often used by other applications as well. So, whose database is it?

    Anyway, good to hear your thoughts on the subject.

  • Thanks for the comment Udi.  On the question of orthogonality of DDD and a Service, I would suggest that just because you can use DDD, RAD or scripting to implement a Service, doesn't make them "orthogonal". :)

    Your point about bluring boundaries is an important one IMHO, and certainly "service" and "component" are terms that are overloaded in use and understanding.  But "application" is probably one term that most people can identify with reasonably easily.  Most basically understand the boundaries of their payroll, ordering and CRM applications.  Often they also understand that each of those applications' implementations may be distributed - with parts of the application communicating with each other through a method of integration - file sharing, shared database, remote method invocation or messaging.

    Does service orientation in the real world really make database or other shared infrastructure boundaries any clearer?

  • There's a difference between sharing infrastructure like a DBMS, or physical database server, and sharing a data source. When two "applications" communicate, although I'd hardly call it that, through a shared data source (what's been called a database), then the boundaries where one application stops and the other starts gets blurred. Whose stored procs are those? Can the other application change them, or add constraints, triggers, etc? What if they do and it breaks your app?

    Communicating, in my book, means letting the listening party decide what to do with the information you send them. Backdooring them through the database does not seem to fit that definition. Regardless of SOA, I would not use a data source as a bounary between apps. Using the messaging features of a DBMS, like Sql Server Service Broker, is an entirely different matter and does fall under the "shared infrastructure" you mentioned.

  • I have just started reading about DDD ... From what i understand SOA is a Distributed Application Architecture . DDD is just a Domain Model.

    DDD just sits inside the Business logic layer of SOA .
    The client doesnt need to know whether DDD is used or any other Model is used to Implement service. Also , SOA never speaks about how u store objects or retrieve objects or aggregation of objects. But the domain model gives detail about repositories , Aggregates .

    SOA is at a higher level than DDD like "if SOA is the PC Architecture , then DDD is the Processor Architecture".

Comments have been disabled for this content.