I'm thinking about applying CQS for my ASP.NET MVC web site, but in a very simple matter. I don't mean CQRS, because I want to use the same data source for query and command parts, and so I don't need event sourcing and other more complex patterns.
So, what I have in mind is:
- use the same database for query and command part
- for the query part, expose database views with entity framework and WCF data services, so that specific views are returned to the client, querying data becomes very easy
- for the command part, expose database tables with entity framework and one-way WCF services, and using DDD principles.
The main thing I want to achieve is:
- simple commands that are executed by one-way service operations, and handled by a rich domain model, client needs to pass only the data that is really needed to perform the command
- flexible querying on simple views, designed for the specific UI of the client
Does this make sense?
So, to answer your question, yes I think it makes sense.
I'm not sure what else you're looking for. I think the approach you're taking makes sense and should give you what you are looking to do.
In my opinion, CQS and CQRS are very similar, where CQRS has the concept of separate read and write stores (and some would argue that the write store may not even be necessary). Event sourcing isn't really part of CQRS - it's an add-on, so to speak, that fits in nicely with the distributed nature of CQRS.
What you're giving up with your approach is some of the scalability of the data since you're flattening the data using views. But if your app doesn't require it, then there's no problem there.
Also, it may be useful to read Udi Dahan's article on when to avoid CQRS. It probably helps justify your decisions. It caused quite a stir when he released it. But between him and Greg Young, they're the experts on CQRS.
I'm not sure if I answered your question or helped, but good luck with your project! I hope this helps.
来源：https://stackoverflow.com/questions/6917843/architecture-simple-cqs