Menu
I am currently working on some proof-of-concept code that follows the CQRS pattern and I cannot find a satisfactory solution to a problem I [think I] have.
The system calculates the impact of market changes against a given portfolio based on specific scenarios.
Portfolios can contain from one to several hundreds of holdings and market scenarios are pre-defined or defined on the fly by the user for a specific request.
In its simplest form the solution to this problem would be a service that returns some values given the input, but in the CQRS case it seems to me that the part that performs the calculation (domain) should not be called by the part that actually returns the data (query).
Considering that a system such as this would easily have several portfolios and that the number of scenarios can also be quite high, I don't think it would make sense to store the results of the calculations.
Anyone has a solution to this issue or can point me in the direction of an article that solves a problem similar to this one?
305
CQRS is a popular architecture pattern because it addresses a common problem to most enterprise applications. Separating write behavior from read behavior, which the essence of the CQRS architectural pattern, provides stability and scalability to enterprise applications while also improving overall performance.
CQRS stands for Command and Query Responsibility Segregation, a pattern that separates read and update operations for a data store. Implementing CQRS in your application can maximize its performance, scalability, and security.
Command query responsibility segregation (CQRS) is a programming design pattern that treats retrieving data and changing data differently. CQRS uses command handlers to simplify the query process and hide complex, multi-system changes.
Kafka is, therefore, a natural choice for implementing CQRS. In an event sourcing architecture, events are the first class citizens. This is different from traditional architectures, in which database is the primary source of truth.
CQRS does not say that you should pre-calculate everything in the write side. When the state of the system changes through a command, events are created and projections listen to these events and create a model that can be used for querying. What this model looks like and what it is used for is up to you. You could even create a projection of a complete 3rd normal form database representation of your system if you want to.
If it would be more practical for you to do these calculations on the read side then I see no problem with doing that, just as long as it is ok to lose the result of the calculations.
151
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
