views:

43

answers:

1

Hello,

I am new to CQRS and confused on how command will write a address change to a customer object

Lets say I have divided customer information into two tables

customer - Domain database

Active Preferred

Customer_Read database

Name,

Address,

Phone,

email

User modifies address of the customer. The address fields are all in read database. there may be 3 or more query friendly tables that is keeping address information.

If I understand the CQRS implementations (sample) Customer Domain (removed Aggregate root) should be publishing event about address change that should be handled by multiple handlers to update each of the table.

How do I implement this when I wont be changing the state of customer object? Do domain have to know that it has address in another database ?

Thank you in advance.

Regards,

The Mar

Update--

After going through more posts on net I am assuming that if the state is not changed by the command no event will be generated to save the domain itself but events will be applied to change the address in query / View Model friendly tables.

A: 

You still need to persist some domain data somewhere in the write persistence. This way the address is stored in this persistence store, event is published after changing it.

This way:

  • if there were no change - we can skip publishing the event
  • domain does not need to know anything about objects that may (or may not) be subscribed to his events.

This logic applies to both persistence in relational DBs (MS SQL with NHibernate, for example) and event sourcing approach.

Rinat Abdullin
@Rinat- your answer does make sense to me. What I was trying to see is ( and after reading and watching Udi's point of view) , if I can remove the non/less volatile properties to read side. If I undestand your reply -ChangeAdressCommand, will first persiste the change to write side and then publish events ( which can be subscribed to by read side handlers). Btw. I enjoy reading your blog and Lokad concept. Whats your take on NCQRS?
TheMar
Yes, you can move less volatile (or simply less important) information directly to the read side (as long as it is not needed for the write side in order to make decisions).
Rinat Abdullin
Re Udi's approach - I liked it in the beginning, but currently I'm shifting more towards Greg's ideas (which is not a consultant like Udi and thus is not biased towards certain technologies). Re NCQRS - it didn't fit my approach.
Rinat Abdullin