Consensus between DDD and Enterprise Architecture

Question

In literature (blogs, articles, books on Enterprise Architecture...), it seems there is a real (and exclusive) appliance of SOA in EA. If we consider DDD and SOA share common architecture principles but differ on many others, what is the place for DDD in the EA discipline ?

Answer 1

DDD and SOA play well together. Usually service boundaries match with your bounded contexts. You design cross-context communication using SOA and it all works. EA does not go deep into how you develop your "services" inside but DDD helps you there.

Answer 2

For me the greatest advantage of DDD is that it makes you do your work when analysing the business domain.

Good understanding of the domain is never a bad thing, and of course this statement holds true for SOA as well. Even more, if you manage to build a common data model for most entities, this improve interoperability because you will be able to build much more standardised services, so you will avoid the need for data mapping and transformation. When you do service composition and/or orchestration common types tend to become a must. So if you put in more work upfront, you're going to have easier times later when your services and inventories get to governance.

As Alexey already stated, DDD and SOA do not interfere and work well together.

Answer 3

In his book, SOA Design Patterns, Thomas Erl describes how softwares end up being composed of and residing in architectural elements which could be technological, platform or resource related. He then explains the importance of technology architecture in service-orientation and it's four common types of which are:

1. Service Architecture
2. Service Composition Architecture
3. Service Inventory Architecture
4. Service-Oriented Enterprise Architecture

For as far as technology architecture is concerned, there is no mentioning of how the services should be implemented (DDD or otherwise). It just emphasises on their existence, their composability and their boundaries.

Domain Driven Design, covers the "how" of software component design. And that's exactly what happens in the book. When narration swings to design patterns, topics such as Domain Inventory and Entity Abstraction come into the picture.

So for as long as a design approach complies to four characteristics of SOA (business driven, vendor neutral, enterprise centric, composition centric) and it's design principles (standardized service contract, service loose coupling, service abstraction, service reusability, service autonomy, service statelessness, service discoverability, and service composability), which in my opinion DDD does, it could be safely used for design and implementation of a software and it's services.

Answer 4

DDD, as one EA guru (I believe it was Gary Booch) once stated, was a result of misunderstanding of EA by the DDD author (in his DDD book, he mixed the concepts from conceptual, logical, physical, implementation, and operation perceptions - a very, very dangerous thing!).

Basically, when you talk about EA, you must always discern between different viewpoints (to borrow the term from Zachman EA Framework) and model the architecture within the boundaries of the specific viewpoint you are concerned with in a particular phase of the EA development process. E.g.

Identify (types)------SCOPE--------Planner perception----Row I ZF

Define (business)-----CONCEPTUAL------Owner perception-----------Row II ZF

Represent (system)----LOGICAL---------Architect perception-------Row III ZF

Specify (technology)--PHYSICAL--------Engineer perception--------Row IV ZF

Configure (tools)-----IMPLEMENTATION--Sub-contractor perception--Row V ZF

Manifest (operations)-INSTANTIATION---Operator perception--------Row VI ZF

In other words, DDD author got it all wrong, he mixed up apples and oranges. Basically, back in early 2000s when he wrote the DDD book, he was not familiar with EA research (the 1st version of Zachman Framework was published in late 80s, but it did not proliferate with the business community for quite some time).