.NET CQRS Frameworks nCQRS vs Lokad.CQRS

Decoupling only works if there really is separation. Consider if you have an ordering system:

• Table: CUSTOMER
• Table: ORDER

If that's all you've got, there's no reason to decouple them. On the other hand, if you have this:

• Table: CUSTOMER
• Table: ORDER
• Table: CUSTOMER_NEWSLETTER

Then you could argue that ORDER and CUSTOMER_NEWSLETTER are part of two totally separate modules (ordering and marketing). Perhaps it makes sense to move these into separate databases (one for each table), and have both modules share access to the common CUSTOMER table in its own database.

By doing that you're simplifying each module, but you're increasing the complexity of your data layer. As your application grows larger and larger, I can see an advantage to separating. There will be more and more "data islands" that really have no relation to each other. However, there will always be some data that cross-cuts all modules.

The decision to put them in different physical databases would typically be based around real-world constraints like frequency of backups, security restrictions, replication to different geographic locations, etc. I wouldn't separate tables into different physical databases just because of separating concerns. That can be handled more simply with different schemas or views.

There are several ways of going about this. You know your team best. It's best to ask yourself at what level of abstraction you need to speak for them to comprehend.

Cqrs is really about seperating read logic from write logic. This is best explained by comparing it to todays layered architecture as promoted by database vendors (video section over on http://dddcqrs.com does a good job at that), mostly because people can relate to it and see how the changes you propose fit into that architecture. You could just stop at the argument that for the purpose of reading data there's no need to jump through all the hoops (of the write logic). No need to go any further (no seperate stores, ddd concepts, messaging, service bus, etc.). That said, there's much more value to be gained, both from a technical and functional perspective, if you pursue further. But again, 1 step at a time. Remember, people in general are not very fond of change (even if it's a good change). There's lots of value in the offspring of cqrs, but it requires careful judgement and assesment if it fits your team (and their maturity). Sometimes it's better to grow together than dragging people into something. Also, don't forget that management is not to be ignored either.