There is a lot of discussion online around whether DDD and SOA can co-exist, and if so, what that looks like. I am of the opinion that they can co-exist and have arrived at a model that seems to work for me. Consider a complex DDD system with several bounded contexts and contrast it to an SOA system – and I am including the flavor of SOA that I describe in this post.
So, how do the two come together? As I have mentioned before, one problem I have with straight-up SOA is that there is no identifiable “core” of the system where the “meat” is. This “meat” is in fact – the domain logic. Now, add to this the fact that the domain is the only thing that deals directly with the database (technically, it’s the infrastructure layer that handles persistence – but you get the idea – it is the domain constructs that are involved in persistence to/from a data store via repositories).
What if we modeled the entire domain as a service? It does not need to be strictly hosted – think of it as a service that is consumed by other services as a library. The repositories combined with the domain objects themselves can replace the accessor/persistor class of services. This makes sense in terms of volatility as well – since the domain really needs to be the part that is least volatile. You can then think of the application layer and the infrastructure layer as being made up of all the other services – and these would still follow the whole utility / computational service / use case handler hierarchy. You would not allow the domain layer to call utility services though – but that is something you would handle through domain events and the like. The presentation layer is still the presentation layer – and is where the UI lives, or the external hosting interface to your services.
The mode of communication between bounded contexts does not change. You can now think of each bounded context as its own SOA subsystem. Communication within bounded contexts would still happen through queues, messages and subscriptions. The application and infrastructure layer would also have “domain event handler” services that handle domain events – I guess you could argue that is just one type of a use case handler. The communication between bounded contexts, as mentioned earlier, stays the same.
A commons library is something I’ve always tried to maintain. The idea is you have something of your own that handles (or at least provides a way to handle) common cross-cutting concerns in all applications that you build. This includes areas such as configuration, logging, security, error handling, data access, dependency injection and caching to name a few. As long as it is kept up to date, it is also a good way to keep up to date with new technologies in these areas. My last attempt at a commons library was during my .NET 2 days – and it worked pretty well for applications that I built back then. I realized recently that I hadn’t really kept it up to date and as a result was not using it. So, I decided to scrap it and build something from scratch that would take advantage of the latest and the greatest that’s out there (that being .NET 4.5 as of now).
One of my key goals was to make the library itself more of a set of contracts, without any dependencies – so that I did not marry myself to any specific technology. Instead, the library would just provide a way for consuming applications to do certain things. I could then build providers that implement these contracts and use various technologies to get the job done. This way, as new technologies emerge, I can incorporate them into my applications by building and hooking up new providers while everything else remains the same. I decided to use MEF as the mechanism to do this – and it also serves as a good dependency injection provider.
The library is called AK.Commons and with its first release is very much in its infancy. It gets the job done for what I need to do today – but I’m pretty sure I will need to add to it quite a bit as I go along. This time around, to make sure I stay engaged in maintaining this (and possibly to gather input and feedback from the community), I have decided to release it on Nuget, open source the code on GitHub, and also put up some documentation.
Over the next few days, I intend to blog some more about the library- particularly my thought process around each concern that the library supports, along with details on some of the providers, my applications that actually use this – and also my plans for the library for the future- a roadmap if you will. Usage and forks of the library and feedback on it is welcome and much appreciated.