cqrs
I am beginning a project and I was wondering If I can use CQRS and Hexagonal architecture in the same project, or in fact they are incompatible.
I read about CQRS and some people agree that it is not an architecture, and more like a pattern.
What do you think?
There are several ways of going about this. You know your team best. It's best to ask yourself at what level of abstraction you need to speak for them to comprehend.
Cqrs is really about seperating read logic from write logic. This is best explained by comparing it to todays layered architecture as promoted by database vendors (video section over on http://dddcqrs.com does a good job at that), mostly because people can relate to it and see how the changes you propose fit into that architecture. You could just stop at the argument that for the purpose of reading data there's no need to jump through all the hoops (of the write logic). No need to go any further (no seperate stores, ddd concepts, messaging, service bus, etc.). That said, there's much more value to be gained, both from a technical and functional perspective, if you pursue further. But again, 1 step at a time. Remember, people in general are not very fond of change (even if it's a good change). There's lots of value in the offspring of cqrs, but it requires careful judgement and assesment if it fits your team (and their maturity). Sometimes it's better to grow together than dragging people into something. Also, don't forget that management is not to be ignored either.
The reason ES is generally not a good idea for top-level architecture ("anti-pattern" has no real meaning anymore) is because it's complicated. Plain and simple.
An ES system is going to be more difficult to conceptualize and develop than a traditional system backed by an RDBMS. Think about it. You are essentially adding another, lower layer (a new "truth") to your application along with all of the plumbing necessary to "project" that layer upward towards your domain. This is not trivial. Not only will you likely lose many of the built-in benefits an RDBMS can provide regarding constraints, type checking, and normalization of your data (an event store is usually a little more free-form), you need to account for things like possible future changes (versioning) and the headache of "retroactively" modifying your event store when you realize you need to fundamentally change some behavior (I promise you this will happen for any non-trivial system). Taken as a whole, ES presents a system that is harder to understand, harder to manage, and harder to change (this may seem like a point of contention, but a well-designed traditional DDD system is easier to change. That's the whole point of DDD right?).
On the other side of the coin, most of the benefits of ES are high-level in nature (introducing another layer to your application certainly doesn't benefit developers). One of the biggest benefits is that ES systems are easier to scale. A single, append-only store with separate read/write models can be scaled with ease. Additionally, as @Ewan alluded to, because your domain is simply a projection of the event store (that is, because you have added another layer), ES systems afford the ability to easily create many different projections of your data (a new command model can emerge without having to make DB schema changes, for example). This can be useful for data warehousing/analytics, but also can help with future-proofing your application.
Now, with the above in mind, we can clearly see that the benefits of an ES system are orthogonal to it's drawbacks: high-level benefits, low-level drawbacks. This is in direct contrast to most other architectures: DDD is all about creating a system that is simple to develop and change at the cost of possible difficulties in scaling etc. This is generally a better trade-off for software systems because they tend to evolve over time, hardware is cheap, and most applications simply don't require a massive scale/throughput.
As such, ES should applied when necessary to help solve a specific problem/domain, not blindly to an entire application (pet projects exempt).
EDIT - As to the question regarding "sharing" events between contexts. Each context needs to "own" it's changes. You don't want a change in one context to directly create a change in another. Doing so will couple them together which defeats the entire purpose of creating two contexts in the first place. This is akin to having two aggregates depend on the same field in a RDBMS. I think you may be misunderstanding the benefit you outline regarding the reconstruction of different models from your event stream. This DOES NOT APPLY to command models. You may only have ONE command model per event stream. Business rules cannot be selectively enforced. And to that end, multiple read models are possible in any system.
More specifically, ask yourself "why" your EmailChanged event is relevant to more than one context. Could it be possible that you haven't divided your contexts appropriately? It looks like you have created contexts around organizational boundaries. This often creates problems. Here is a short discussion of the topic:
http://udidahan.com/2016/02/19/ask-udi-two-services-operating-on-the-same-entity/
It's important to understand that your entities and bounded contexts will often be "discovered", not decided upon based on some holistic knowledge of your business. Model according to behavior!
Best Answer
This is like asking if you can use utensils to eat ice cream. (Yes you can. I recommend a spoon.)
CQRS asks you not to mix together the complexity needed to perform queries with the complexity needed to update.
Hexagonal Architecture asks you not to mix the complexity of your input and output ports with your central application logic.
So yes you can do both. But doing one doesn't mean you've done the other.
If you did, it could be diagrammed like this:
That shows where things go. Imagine adapters between the hexes that help isolate the central application logic from DB and UI changes.
Many of these fancy principles are really just about isolating things. It's not that you can't make something that works if you ignore them. But following them means the impact of a requirements change is isolated. It doesn't make it easier to write the code nearly as much as it makes it easier to maintain the code.
Hexagonal, onion, and clean architecture all seem to be different names for the same thing. Authors love to steal an idea and give it a new name.