CQRS/ES by default

We think this blip was misleading and that its message could be misinterpreted. So, we introduced a new BLIP in adopt for CQRS/ES, with some trade-off advice.

CQRS (Command Query Responsibility Segregation) is a pattern that separates the responsibility for handling read and write operations into separate components.

Event sourcing is a software development pattern that stores and reconstructs an application's state by capturing and replaying a sequence of events.

While CQRS/ES both can be useful in certain contexts, it is not always the best approach to use by default.

One reason why using CQRS/ES by default may be a bad practice is that it adds complexity to the system. Separating read and write responsibilities into different components can make it more difficult to understand how the system works as a whole, and can increase the time and effort required to develop and maintain the system.

Another potential downside is that it can lead to over-engineering. CQRS/ES may be a good fit for complex systems that require fine-grained control over read and write operations, but for simpler systems, the added complexity of implementing CQRS may not be necessary and can actually hinder the development process.

We should consider the trade-offs involved in using CQRS/ES, including increased complexity and potential over-engineering, before deciding whether to adopt it. There are simpler patterns to follow to implement domain models that may be more appropriate for your use-case.