Lokad.CQRS Architecture Style: Plans and Boundary
Sunday, April 15, 2012 at 15:11Все фигня, кроме пчел, да и пчелы - тоже фигня (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.
Reader Comments (4)
Can you expand on what you dislike about nservicebus?
Akash, the way it has was turned from Open Source project into commercial software. It's perfectly legal, but just plain wrong.
As for the service bus - it is ok.
What are some of the elements that facilitate communication between different BCs in a context map? If BCs can be implemented using various tactics such as CQRS, POC+ORM, then how are context maps "implemented"? Regardless of technology, BCs always communicate using messages, but there could be a variety of patterns here as well. Maybe like: http://www.eaipatterns.com/..
Actually, you don't always even need messages (or sometimes you can't use them).
Sometimes command messages can be replaced by synchronous calls to application service (this is a simpler approach than commands, which has it's own pros and cons). Idem for event messages - they can be replaced with either in-memory dispatch or direct calls to the read models from the application service.
Then, on more technical level, you can have service buses, use of lower level messaging (from AMQP down to ZMQ). Another potential trick is with streaming gigabytes of data that don't always "fit" into the message channel.
However, for the sake of simplicity, general rule of thumb is to use messaging and hide all the infrastructure details from the domain implementation. This way you can evolve and optimize the infrastructure around context map without affecting actual BCs.