After OASIS SOA RM  standard graduated Service-Oriented Architecture (SOA) from IT incubator by opening it toward busienss, many asked questions about relationship between SOA and Domain-Driven Design (DDD) . Some experts employed geometry trying to explain if those two orthogonal, opposite, or parallel. With this overview, I am starting a series of posts where I hire co-centred circle geometry and explain how service orientation meets domain-driven approach.
I will follow OASIS SOA RM and RA-draft in interpretation of what service orientation (SO) means, what is SOA and what is service, which allows considering SOA as a business-oriented consumer-centric methodology driven by orientation on service behaviour. Let me also outline that SO has become the basis of new versions of ITIL  that is de-facto standard for implementing Information Technology (IT) function in the organisations.
Many acknowledge the connection between SOA and DDD. For example, Udi Dahan says: "I am working with DDD in an SOA context". Boris Lublinsky collected opinions about SOA and DDD  of several authors such as Tomas Karlsson, Colin Jack, Ashley Fernandes, and Casey Charlton. The opinions varied from the Ashley's consideration that DDD is the technique for defining business services to the warnings articulated by Colin about dissimilar development habits within OO and SO approaches. Alex Hoffman , on another hand, suggests that SOA and DDD are unrelated because DDD conveys service implementation while for SOA the implementation of the service is unimportant. Nevertheless, I concur with the words "DDD is for building the domain logic within coarse grained SOA services" assigned to Bill Poole .
So, we assume that SOA and DDD are complimentary approaches because DDD provides capabilities the services refer to in their Service Descriptions and Service Contracts . However, it seems that there is a disconnection between the abstract and guide-like SOA and very concrete DDD style. I think, it does not make sense trying to define which one is more important or which one of them reflects the business better. The more important is to find how the abstraction becomes the concrete.
DDD teaches that: 1) a model should be the foundation of complex domain designs, and 2) the primary focus for most software projects should be the domain logic. The domain-specific model that preserves service-oriented principles is the piece missed between SOA and DDD, between methodology and implementation. The first thing we might do is to recognise self-explanatory Domain Service-Oriented Modeling (DOSOM©) as a bridge between SO approach and DDD, and then project SO principles on the domain design. We can use DOSOM© for different industrial domains such as Oil & Gas, Healthcare, kindergarten, and even ice-cream kiosks, because it is a domain agnostic approach that targets domain specific business tasks at the model level with no technical constraints for the model realisation.
(for Part 2, click here)
1. Reference Model for Service Oriented Architecture 1.0, OASIS, http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf
2. Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003
3. Welcome to the Official ITIL® Website http://www.itil-officialsite.com/home/home.asp
4. Udi Dahan, Re: Domain-Driven Design: Implications to SOA? http://it.toolbox.com/blogs/distributed-systems/re-domaindriven-design-implications-to-soa-13391
5. Boris Lublinsky, Is There a Symbiosis Between SOA and DDD? InfoQ http://www.infoq.com/news/2008/09/SOADDD
6. Alex Hoffman , DDD and SOA Are Unrelated, http://weblogs.asp.net/ahoffman/archive/2006/09/09/DDD-and-SOA-Are-Unrelated.aspx
7. Bill Poole, BLOG, http://bill-poole.blogspot.com/2008/04/domain-modelling.html