Living In The Enterprise
1701D? 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 Service)
The foundation of SOA is an environment of distributed systems talking via messages, sent between services, probably over message busses – not applications like DDD
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, Value Objects, 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.