cqrs

Event Sourcing: Events that trigger others & rebuilding state

怎甘沉沦 提交于 2019-12-02 23:29:18
I'm struggling to get my head around what should happen when rebuilding the model by replaying events from the EventStore, in particular when events may trigger other events to happen. For example, a user who has made 10 purchases should be promoted to a preferred customer and receive an email offering them certain promotions. We clearly don't want the email to be sent every time we rebuild the model for that user, but how do we stop this from happening when we replay our 10th PurchaseMadeEvent ? Events chaining can be very tricky and easily run out of control, so I'd avoid it as much as

Command Validation in DDD with CQRS

五迷三道 提交于 2019-12-02 22:05:33
I am learning DDD and making use of the CQRS pattern. I don't understand how to validate business rules in a command handler without reading from the data store. For example, Chris wants to give Ashley a gift. The command might be GiveGiftCommand. At what point would I verify Chris actually owns the gift he wants to give? And how would I do that without reading from the database? Tomasz Jaskuλa There are different views and opinions about validation in command handlers. Command can be rejected , we can say No to the command if it is not valid. Typically you would have a validation that occurs

Akka.Net VS MS Orleans Comparison [closed]

家住魔仙堡 提交于 2019-12-02 21:40:40
Closed . This question needs to be more focused. It is not currently accepting answers. Learn more . Want to improve this question? Update the question so it focuses on one problem only by editing this post . I've started implementing several LOB application with CQRS/ES and for this evaluating: several EMS: NServiceBus, MassTransit, RhinoMessageBus Akka.net + DDDD MS Orleans + DDDD There are lot of comparisons of different EMSs but no evaluations of Actor Frameworks. So, could you please compare Akka vs Orleans, namely: features presents conciseness of syntax (Akka is line-by-line porting

Add validation to a MediatR behavior pipeline?

隐身守侯 提交于 2019-12-02 21:35:46
I'm using ASP.NET Core, the built-in container, and MediatR 3 which supports "behavior" pipelines : public class MyRequest : IRequest<string> { // ... } public class MyRequestHandler : IRequestHandler<MyRequest, string> { public string Handle(MyRequest message) { return "Hello!"; } } public class MyPipeline<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse> { public async Task<TResponse> Handle(TRequest request, RequestHandlerDelegate<TResponse> next) { var response = await next(); return response; } } // in `Startup.ConfigureServices()`: services.AddTransient(typeof

Is it possible to do DDD and REST interface and language mapping?

断了今生、忘了曾经 提交于 2019-12-02 19:45:53
REST has a uniform interface constraint which is the following in a very zipped opinion based format. You have to use standards like HTTP, URI, MIME, etc... You have to use hyperlinks. You have to use RDF vocabs to annotate data and hyperlinks with semantics. You do all of these to decouple the client from the implementation details of the service. DDD with CQRS (or without it) is very similar as far as I understand. By CQRS you define an interface to interact with the domain model. This interface consists of commands an queries classes. By DDD you define domain events to decouple the domain

Handling duplication of domain logic using DDD and CQRS

我怕爱的太早我们不能终老 提交于 2019-12-02 19:32:29
I'm experimenting with DDD + CQRS and I can not understand how to handle this domain logic duplication problems: First, about duplication across domains: Scenario 1: Let's say I have some application which handles office employees. I have 3 bounded contexts: Programmer department, QA department and Audit Department. Each BC has it's own AR: "Programmer", "Tester", "Worker". They are 99% different, with different logic in each, however, each of those have "Name", "Surname" and a simple method "getFullName" which concatinates those two. Question 1: How do I (and should I?) make that the common

CQRS Commands and Queries - Do they belong in the domain?

主宰稳场 提交于 2019-12-02 17:29:40
In CQRS, do they Commands and Queries belong in the Domain? Do the Events also belong in the Domain? If that is the case are the Command/Query Handlers just implementations in the infrastructure? Right now I have it layed out like this: Application.Common Application.Domain - Model - Aggregate - Commands - Queries Application.Infrastructure - Command/Query Handlers - ... Application.WebApi - Controllers that utilize Commands and Queries Another question, where do you raise events from? The Command Handler or the Domain Aggregate? Tomasz Jaskuλa Commands and Events can be of very different

Real life experience with the Axon Framework [closed]

不打扰是莪最后的温柔 提交于 2019-12-02 16:33:37
As part of researching CQRS for use with a project, I ran across the Axon Framework , and I was wondering if anyone has any real life experience with it. Just to be clear, I'm asking about the framework, not CQRS as an architectural pattern. My project already uses Spring and Spring Integration which fits nicely with Axon's own requirements, but before i dedicate a lot of time to it, I would like to know if anyone has some first hand experience. In particular I'm interested i possible pitfalls that are not immediately apparent from the documentation. FrenchSpidey The framework relies heavily

How to adapt CQRS to projects? [closed]

ぐ巨炮叔叔 提交于 2019-12-02 16:17:05
I came across a new term named CQRS (Command Query Responsibility Segregation) which states that the conceptual model should be split into command model and query model as a typical CRUD model in which the command and query happens in the same model. The article has all theory information. I don't understand how I should implement this in a project with ASP.net MVC3, EF 4.3 and jQuery. Can anybody suggest me how to practically implement it in my project? CQRS Journey is a good place to start. I also suggest you watch A Journey into CQRS on Channel9. Anyway, the best thing to learn CQRS is to

CQRS - The query side

不羁岁月 提交于 2019-12-02 15:33:00
A lot of the blogsphere articles related to CQRS (command query repsonsibility) seperation seem to imply that all screens/viewmodels are flat. e.g. Name, Age, Location Of Birth etc.. and thus the suggestion that implementation wise we stick them into fast read source etc.. single table per view mySQL etc.. and pull them out with something like primitive SqlDataReader, kick that nasty nhibernate ORM etc.. However, whilst I agree that domain models dont mapped well to most screens, many of the screens that I work with are more dimensional, and Im sure this is pretty common in LOB apps. So my