I use powerpoint.

Thanks in advanced.

That would be great – thanks.

Mind if someday I translate this article in french and link back to your post ?

best
joseph

I wouldn’t say that performance/scalability are the deciding factors towards choosing CQRS – but they do contribute. The primary property of a system that would make it a good fit for CQRS is whether it is collaborative – ergo multiple users/actors working in parallel on a shared set of data.

It is likely that there are parts of a system that are collaborative, and parts that aren’t. As such, CQRS should only be used for the collaborative parts.

Another question came to my mind: would you recommend CQRS only for application when performance/scalability is of the uttermost importance or more as a pattern applicable to any application, like some intranet one?

Having watched some of your talks on infoq I kind of had the feeling CQRS so much reducing the domain to its core that it would end up providing value anywhere, but most likely I’m just being over enthusiastic…

thanks again
best

If only I had the time

Please oh please work on a book that will save me a lot of time and headache trying to google cqrs

Thanks a lot for this post, which indeed clarifies the CQRS topic.

You said earlier you would post on Event Sourcing soon, but I didn’t find any related post (apart from the current one). Am I missing something ?

It would be nice to have such a clear explanation on event sourcing, so.

Anyway, thanks a lot

The technical form of using one-way commands enables scaling writes, and serving reads off of a type of cache has alway sbeen a way to scale queries. All that being said, if users don’t need to collaborate, each one is working on their own data, then you have an easily partitioned domain by user, rather than by separating reads and writes.

I’d say that if the data does not need to be operated on by multiple actors collaboratively, then you might not need this approach. Highly complex non-collaborative domains may need it as well.

Actually, the method is an aggregate root (Stock) method, which can naturally navigate its childs to do calculation. The method has only one responsibility – to calculate the weighted average cost of the root entity.

Anyway, thanks for your insights.

Regards,
Michael Leung

It sounds like that calculation component is doing too much, violating the single responsibility principle.

Thanks for your explanation. It so happens that the “calculation component” is one of the stock’s business methods and it is used in commands such as “Create purchase order”. This business method can navigate from itself to its purchase histories, shipments, exchange rates & etc. Because Hibernate will do all the OR mappings, we don’t need to pre-fetch all the required histories, shipments, exchange rates and past them to the “calculation component”.

For CQRS, do I need to duplicate the business method’s logic to the “calculation component”? (same logic, different implementation because one based on ORM and another is functional component with pre-fetched data sets as parameters)

Regards,
Michael Leung

What you’re describing is handled by a “calculation component”, a pure functional component that doesn’t access any data on its own but is fed data from the outside. The client passes in the data from the persistent view model into the calculation component and displays the results of the calculation. The query itself remains very simple, although the calculation itself may be quite complex.

I am practicing DDD and agreed that the query portion (or context) is unnecessarily complex. However, queries are not always simple relational retrievals. Take stock’s weighted average cost as example. It may need to navigate a lot of entities, executing these entities’ methods before arriving at the cost for the stock. The query does involve Business Rules and behaviors exists in Queries, not just in Commands.

If all unit costs are pre-calculated in the cache, then we may be doing more than necessary. How to deal with this?

The other thing (or multiple things) could be in the validation component and/or the controller for the command making use of data in the persistent view model to decide not to send a command. In short, it’s not on the entity and not part of the entity’s interface.

I understand that this doesn’t follow traditional OOAD, but I’ve found it extremely effective.

Some computed values may indeed be persisted in the master db, others which are simple aggregations (like sums) that are only needed for views can be computed without the domain.

What confuses me is that i am used to thinking in a traditional OOAD. Hence, i would typically assign responsibility to where it belongs, regardless of the frequency of change. The internal implementation will care about frequency of change and hence perhaps externalizing to scripting, rules, db etc, but thats internal details.

So in order to initialize the ‘persistent view model’ for the FIRST TIME,I need to use the domain model In order to compute all computed fields

Thanks

Why do you assume that values computed by the domain model aren’t persisted there? Arguably these computed values are actually the most interesting things in the domain representing most closely the language of the domain experts.

If an update of the persistent view model failed (threw an exception), it would be retried a configurable number of times and then sent off to an error queue, which an administrator is likely monitoring. This tends to happen most often when installing a new version of something as the kinks are worked out of the system – it very rarely happens otherwise.