In April of this year, I spent a week in New York attending Udi Dahan's Advanced Distributed Systems Design course. It was a great course that taught me a lot and I've been thinking about it and trying to apply those teachings since.
I will probably blog more about the course in the future. But just to give a 10,000ft view for purposes of this post, Udi preaches service-oriented architecture in which each service is totally autonomous and owns its data completely. They communicate via events using messaging. The separation of these services is kept complete to the point that the data is own aggregated on the client by retrieving the data from each service and using a UI framework like Backbone to aggregate the data.
I spent a few lunch hours at work whipping up an insanely small sample web application that:
- Uses messaging (NServiceBus) as its backbone to send commands from the UI to services and from services to other services.
- Composes a UI from read services provided by each service.
It is available for anyone to download via:
http://github.com/ddonahue/BusinessCapabilitiesSample
Let me know if you any problems getting the code or getting it to run. I built it in VS2012 and it targets .NET 4.5.
My hope was that, although simple, it provides a starting point to show people how a system broken out into services could be built. I hope it lets people start to reason about how a service-oriented architecture might look, how messaging works, how UI composition could work, etc. I'm hoping it facilitates conversation. I encourage questions and comments.
One thing I'd like to mention is that I did NOT compose data in the web client. I found it easier to compose data from different services in the MVC controllers, or presentation layer. This was done for ease and also because javascript UI composition was one of the most debated topics in the course. I personally find it to be a good suggestion for complete and total autonomy between services, but I think having each service expose a read service to your presentation service (whether that be web or thick client) is a good tradeoff.
I may do a series of follow-up blog posts where I highlight different parts of the project with a more in-depth discussion.
Please bear in mind that it's quite obviously a toy application and a lot of care was NOT put into it around removing duplicate code, best practices, etc.
Hopefully someone finds this useful.