Все фигня, кроме пчел, да и пчелы - тоже фигня (c)
Ответ старого пчеловода на вопрос о смысле жизни.
Over the course of last few months I was lead to a simple realization: CQRS/ES is not a top-level architectural style, but rather a tactical choice. Yes, I know that this is what people have been talking about for all the time; but hearing is one thing, while understanding is the other.
This simple realization makes CQRS/ES much less important on the big picture (or maybe my own picture just got bigger). So, when we have a complex problem at hand, we start by identifying natural boundaries around some core business concepts, which would let us identify separate bounded concepts. Only then we can decide about architectural styles that could be applied within a specific bounded contexts. (I went into more detail on that in my last post)
Lokad.CQRS (in it’s current anatomy branch on github) is currently a sample project demonstrating my favorite way of implementing bounded contexts that are:
- rich in business behavior;
- require rapid changes and releases (we are rapidly learning about environment);
- require elastic scalability and ability to be deployed to various cloud environments.
This is a sharp tool, that requires discipline as well as people with certain knowledge and experience. On the bright side - it is verified by practical experience, cloud outages and startup environment.
As you can see, we’ve just defined applicability boundaries of Lokad.CQRS+ES approach. This actually helps it to focus and stop attempts to handle all possible scenarios. The approach works and I don’t plan a lot of changes any time soon (maybe just more documentation and tooling improvements).
My current friction points currently reside on a higher level - making multiple bounded contexts (that are deployed across clouds and datacenters) to work together. Especially, when you have a rapidly growing software-as-a-service company that tends to introduce multiple services and changes per year; where each one brings new bounded contexts and details on the global strategy map (and these guys just don’t know how to stop).
Once again, I’m happy with the current state of Lokad.CQRS architecture style and don’t expect a lot of changes to it. CQRSGuide will probably gradually transition into a documentation guide across that specific architecture style.
Please keep in mind, that this approach is just one of many out there. There are two other options in .NET world that I want to highlight:
- NServiceBus and things that Udi Dahan teaches. I might have strong personal disapproval of values and grounds of his approaches, however they work in world’s largest companies. You can’t argue with that.
- Microsoft CQRS P&P Journey, which has a strong technical team with a diverse advisory group. In my opinion they are focusing too much on debates and less important technical things, but the progress Microsoft is making is impressive. I wish them luck.
If you are interested in pushing state of the art in this area, I encourage you to dive deeper, learn and share what you have learned. It does not matter, which project you would choose for that - you will gain and give a lot either way.