cqrs

I'm trying to implement a simple CQRS-application example. This is a structure of my "Command" part: public interface ICommand { } //base interface for command handlers interface ICommandHandler<in TCommand> where TCommand: ICommand { void Execute(TCommand command); } // example of the command public class SimpleCommand: ICommand { //some properties } // example of the SimpleCommand command handler public class SimpleCommandHandler: ICommandHandler<SimpleCommand> { public void Execute(SimpleCommand command) { //some logic } } This is interface ICommandDipatcher . It dispatches a command to its

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

Please explain why modifying many aggregates at the same time is a bad idea when doing CQRS, ES and DDD. Is there any situations where it still could be ok? Take for example a command such as PurgeAllCompletedTodos. I want this command to lead to one event that update the state of each completed Todo-aggregate by setting IsActive to false. Why is this not good? One reason I could think of: When updating the domain state it's probably good to limit the transaction to a well defined part of the entire state so that only this part need to be write locked during the update. Doing so would allow

EventSourcing works perfectly when we have particular unique EntityID but when I am trying to get information from eventStore other than particular EntityId i am having tough time. I am using CQRS with EventSourcing. As part of event-sourcing we are storing the events in SQL table as columns(EntityID (uniqueKey),EventType,EventObject(eg. UserAdded)). So while storing EventObject we are just serializing the DotNet object and storing it in SQL, So, All the details related to UserAdded event will be in xml format. My concern is I want to make sure the userName which is present in db Should be

I'm having a debate with my coworkers in the design of the read side of a CQRS application. Option 1: The application read side of my CQRS application returns DTOs, e.g: public interface IOrderReadService { public OrderDto Load(int id); } public class SomeController { public ActionResult SomeAction(int id) { var dto = ObjectFactory.GetInstance<IOrderReadService>().Load(id); var viewModel = Mapper.Map<OrderDto, SomeViewModel>(); return View(viewModel); } } public class SomeOtherController { public ActionResult SomeOtherAction(int id) { var dto = ObjectFactory.GetInstance<IOrderReadService>()

1. 引言 微服务架构现在很热，到处可以看到各大互联网公司的微服务实践的分享总结。但是，我今天的分享和微服务没有关系，希望可以带给大家一些新的东西。 如果一定要说微服务和CQRS架构的关系，那我觉得微服务是一种边界思维，微服务的目的是为了从业务角度拆分（职责分离）当前业务领域的不同业务模块到不同的服务，每个微服务之间的数据完全独立，它们之间的交互可以通过SOA RPC调用（耦合比较高），也可以通过EDA 消息驱动（耦合比较低）。 1.1 基本概念 微服务架构和CQRS架构的关系：每个微服务内部，我们可以用CQRS/ES架构来实现，也可以用传统三次架构来实现。 1.1.1 聚合 VS 聚合根 首先，我们需要先理解DDD中的 聚合、聚合根 这两个概念。 聚合 ，它通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚，并避免了错综复杂的难以维护的对象关系网的形成。聚合定义了一组具有内聚关系的相关对象的集合，我们把聚合看作是一个修改数据的最小原子单元。 聚合根 ，每个聚合都有一个根对象，根对象管理聚合内的其他子对象（实体、值对象）；聚合之间的交互都是通过聚合根来交互，不能绕过聚合根去直接和聚合下的子实体进行交互。 上面的例子中，Car、Wheel、Position、Tire四个对象构成一个聚合，其中Car是聚合根；Customer也是聚合根

EDITH says (tl;dr) I went with a variant of the suggested solution; keeping all ICommandHandler s and IQueryHandler s potentially aynchronous and returning a resolved task in synchronous cases. Still, I don't want to use Task.FromResult(...) all over the place so I defined an extension method for convenience: public static class TaskExtensions { public static Task<TResult> AsTaskResult<TResult>(this TResult result) { // Or TaskEx.FromResult if you're targeting .NET4.0 // with the Microsoft.BCL.Async package return Task.FromResult(result); } } // Usage in code ... using TaskExtensions; class

My team and I have been discussing using the CQRS (Command Query Responsibility Segregation) design pattern and we are still trying to asses the pros and cons of using it. According to: http://martinfowler.com/bliki/CQRS.html we haven't seen enough uses of CQRS in the field yet to be confident that we understand its pros and cons So what do you guys think, when does a problem call for using CQRS? CQRS is not a pattern that encompasses the whole application. It is a concept that builds on Domain Driven Design (DDD). And an important strategic concept of DDD is the so-called Bounded Context . In

Looking for some suggestions for useful discussion groups, articles, success stories, reference apps, and tooling (.Net) on the subject of event sourcing. I am already familiar with: Fowler's article: http://martinfowler.com/eaaDev/EventSourcing.html Greg Young's Article (with downloaded docs in the comments): http://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/ Greg Young's excellent (draft) article on DDDD: http://abdullin.com/storage/uploads/2010/04/2010-04-16_DDDD_Drafts_by_Greg_Young.pdf Anything else I should be reading and looking at? quentin-starin You should look at this