Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
DDD: Living In The Enterprise

No, not that Enterprise!

The other Enterprise – the big amorphous one that organisation spent a fortune putting SOA around.

Domain Driven Design appears to be at odds with large scale distributed systems, it is after all  methodology to design and write application software, and in SOA we don’t have applications – we have services (this is one of those times I don’t mean Domain Services")

The foundation of SOA is an environment of distributed systems talking via messages, sent between services, probably over message busses – not applications like DDD

Download the eBook of the series so far …

What is SOA Anyway?

Nice try – I like to argue, but you won’t get me started on a discussion of what SOA is, why it exists, whether it exists, or any silly questions like that. For the sake of this discussion, let us just presume that if you are interested in SOA you probably have what I like to refer to as a VBS … a VERY BIG SYSTEM! (you may not of course, but someone may have decided that SOA would magically solve all your IT problems, so you have it anyway)

Our Ecommerce Example

Let us return to the ecommerce scenario I have used a few times in this series. This could be a single web application, front end coded with MVC, back end written with DDD, talking to an ORM, producing orders, and sending those through to your sales guys. That doesn’t sound very “complex” – and one of the criteria I mentioned earlier as being suitable for DDD were complex applications.

As it happens, an ecommerce website is a pretty poor example for a DDD application – there is little logic, lots of data retrieval and updating, and some pretty graphics. That is, unless you are Amazon.

OK, I’m going to bet you aren’t Amazon if you are reading this, but let’s presume you have a large sales operation, thousands of orders a day, complex pricing and discount models, departments for the warehouse and the delivery operation, billing and accounts systems to talk to … now you have a complex application. Sure, on the front end web servers it is much the same if on a larger scale, but behind the scenes, much more is going on.

And if you have all that, then I’ll bet you got all cosy with SOA at some point too. You probably have services for Billing, Credit Control, Warehouse and Packing, Stock Control, Delivery, and a lot more.

Earlier on we talked about Bounded Contexts in DDD. I didn’t mention at the time, but there was probably an assumption that these were just other parts of the application. For simpler systems they may well be, but as one of the criteria for a Bounded Context is that it has all it’s own code and data, the Bounded Context could be local, or remote, depending on your needs.

SOA Services as a Facade to Bounded Contexts

Separation at a local level is good for isolating change and for keeping a logical split of things that do not belong together. On a wider scale, separation allows you to distribute components of a DDD application as the enterprise requires.

An individual Bounded Context in DDD is a self contained application, it just doesn’t have a user interface like a traditional application does. Instead it has a Context Map which could well be the set of services that fulfils our requirement to play nicely in the SOA Enterprise. These services could be old fashioned web services, or a REST layer, depending on the requirements, they can talk via a message bus, via synchronous or asynchronous requests, or via RPC requests.

Within the Bounded Context we have a full Domain, we have a full set of Entities, VOs, Domain Services, Repositories and a persistence layer. So we have our DDD application – and we can have as many or as few of these as we need.

In Conclusion

When you need to think of a distributed system, think of individual Bounded Contexts as miniature applications sitting behind a services layer.


InfoQ Free eBook : Domain Driven Design Quickly
Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)


1) Domain Driven Design: A Step by Step Guide
2) DDD: The Ubiquitous Language
3) DDD: Bounded Contexts
4) DDD: There Is No Database
5) DDD: Command Query Separation as an Architectural Concept
6) DDD: Entities and Value Objects
7) DDD: Where is the Code?
8) DDD: Download an eBook of the Series
9) DDD: Aggregates and Aggregate Roots
10) DDD: Services
11) DDD: What Kind Of Applications Is It Suited To?
12) DDD: The Repository Pattern Tags: DDD,Domain Driven Design,Practices and Principles

Posted 02-21-2009 9:25 AM by Jak Charlton



DotNetShoutout wrote DDD: Living In The Enterprise - Casey Charlton - Insane World
on 02-22-2009 11:44 AM

Thank you for submitting this cool story - Trackback from DotNetShoutout

Reflective Perspective - Chris Alcock » The Morning Brew #292 wrote Reflective Perspective - Chris Alcock » The Morning Brew #292
on 02-23-2009 3:38 AM

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #292

Think Before Coding wrote Domain Driven Design Step By Step
on 02-24-2009 9:59 AM

Casey Charlton is moving his DDD series on a wiki site so that every body can put it’s personal touch. You can find it and participate at : Expect me to write there !

IHateSpaghetti {code} wrote Blog Carnival #14
on 03-01-2009 1:08 PM

Software architecture Evolutionary Design and Acyclic componentization by Patrick Smacchia Carnival of

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)