Non-Domain Model update in CQRS

Question

In attempt to understand CQRS I created a small application which has Command Executor and event source. By my understanding the changes in domain model are triggered through commands. The domain model then generates the events to update the read model using denormalizer.

But in many cases there may be updates which are non-trivial for the domain. Like user changing his own profile picture. For requirements like these, what is the best way to implement?

I believe that using command will be overkill because the domain model as such doesn't change.

I tried to search for this question but didn't find the answer...

Why is updating a profile picture "non-trivial"? Why is using a command overkill? The domain does change; namely the profile picture changes. It may be the case that CQRS is overkill for a particular use case. — eulerfx
exactly, just to implement this feature CQRS is an overkill. The current domain which I am trying to implement is for Insurance/Underwriting...and by my experience I definitely know its not a overkill for domain/reqiurements we have. My question is what is the best way to implement this particular case of changing profile picture. Will it logical to just go ahead and write the read model/will it be a bad design? — Abhay Naik
Why not just implement with a simple UserProfileApplicationService which contains a method called ChangeProfilePicture. — eulerfx
What will ChangeProfilePicture do? Either it will go ahead and directly update Db or by CQRS it will trigger command like ChangeProfilePictureCommand which will in turn trigger a event in my event source like OnChangeProfilePicture, which will ultimately update the profile picture...Which is better approach by design? — Abhay Naik
It will update the DB directly, bypassing CQRS. It can still raise events, which can in turn update any caches. The best approach depends on existing infrastructure that you have in place. If a CQRS architecture is already in place, then using a command just like you would for other domain changes, isn't overkill because the change is part of the domain and should be expressed as such. — eulerfx

Dennis Traub Dennis Traub · Accepted Answer · 2012-10-23T05:24:08

Don't mix CQRS and CRUD. Either the Bounded Context is suitable for CQRS or it's not. Your pet project probably isn't. But once you decide to apply the CQRS architecture style, you should stick with it.

Commands are trivial. And since you're already using Event Sourcing as well (which is not a prerequisite for CQRS btw.) you shouldn't bypass it for single use cases. Things rapidly become quite messy once you have multiple philosophies in place.

As far as directly writing to the Read Model goes: What if your Read Model goes out of synch, gets corrupted or must be modified and you have to rebuild it? If there's no related event, how should the Read Model know that something happened then?

There is one thing you can bypass if there's no domain behavior: You can just use a Transaction Script (POAA) in your command handler and publish the event from there without invoking the domain.

Long story short: You can happily mix styles in multiple isolated parts of your application (i.e. CQRS in one BC, CRUD in another) but inside a single BC you should stay consistent.

Non-Domain Model update in CQRS

1 Answers