CQRS infrastructure

[hikalkan]

Investigate the EventFlow framework:

Source: https://github.com/eventflow/EventFlow Document: http://docs.geteventflow.net/

[tomlewandowski]

What do you think about this? https://www.youtube.com/watch?v=_lwCVE_XgqI https://github.com/JasonGT/NorthwindTraders

and using CQRS + MediatR?

[hikalkan]

Thanks @tomlewandowski for sharing. Will take a look.

[kegumx]

HI, Is there any progress？

[hikalkan]

Not worked on this yet.

[GFoley83]

Command / Query segregation via MediatR is the only thing I've really been waiting on for ABP.

Some refactoring of the event bus and background job service layers could also be done to leverage the MediatR notification pipeline for event dispatching.

[tomlewandowski]

@hikalkan I found a very nice repository that is a very good reference to DDD and CQRS. https://github.com/kgrzybek/modular-monolith-with-ddd What do you think about this two building blocks?: https://github.com/kgrzybek/modular-monolith-with-ddd/blob/master/src/BuildingBlocks/Domain/TypedIdValueBase.cs

https://github.com/kgrzybek/modular-monolith-with-ddd/blob/master/src/BuildingBlocks/Domain/IBusinessRule.cs

This is another great resource: https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

[pranavpatil19]

set priority high and please move to milestone 1.0

[hikalkan]

Can't move it to 1.0, it is very close to release 1.0 and we can't add new features to 1.0.

[pranavpatil19]

is this module move to 1.1

[hikalkan]

We will see, can't promise.

[pranavpatil19]

. i request you because i want to integrate CQRS With Rabbitmq . if you take this high priority after 1.0 release its really helpful

[GFoley83]

@tomlewandowski that video you linked to was absolute gold and I think perfectly showcased how well MediatR would slot into the current ABP solution design. It's a perfect fit.

[ramax495]

Any progress on CQRS + MediatR ?

[pranavpatil19]

i am also waiting for this module.... 2year old request.

[hikalkan]

i am also waiting for this module.... 2year old request.

Yes, but v1.0 has been released just 1 month ago :) We don't want to work on new features while leaving current feature incomplete & undocumented. Built-in CQRS infrastructure on the road map, but can't promise on any date.

[thiag0coelho]

Is there room for this feature in 2.2?

[maskalek]

Hey guys. Any progress/news? Considering option to migrate on your framework and but we would really love to keep working with MediatR.

[maulik-modi]

Any update on MediatR?

[kegumx]

+1

[jader1313]

I too would appreciate the implementation of CQRS + MediatR

[feynmanloo]

Any progress on CQRS + MediatR ?

[tunechr]

Hi Guys, Just looking at an evaluating abp.io I've used zero in the past and really liked it

Can I check where this feature thread is in planning?

For my clarification, as CQRS and Event Sourcing are related but not the same... but we are discussing both here (and clean architecture) so I'm a bit confused as to what this feature would be?

I'd love to get to the point where we have an event sourcing model, or at least a stronger event model which can then feed into features such as automation and workflows, as well as opening up options for CQRS for developers.

I believe this is a missing enabler for the abp core platform and it's something that I've done manually at the moment using MediatR and a lot of bespoke code in abp.zero... so hoping that can be part of the new platform :)

Imagine being able to use something like elsa workflow / camunda (or your own tool) to be able to allow users to create their own actions and triggers and create automation such as :

• When [event] then [action]
• When someone creates a user then add them to the onboarding workflow
• When someone creates a tenant then send an email to the marketing team
• When someone marks an invoice paid then send a message in teams to accounting. or To be able to build out a BPMN workflow using these events and activities.

Just my thoughts :)

[barnybadzoo]

CQRS + MediatR.. any plan to implement this soon? Is there a roadmap so see when its planned ? I am also evaluating abp currently.. Would be a great step ahead if you plan this

[maulik-modi]

@barnybadzoo, @tomlewandowski and @hikalkan , have you checked https://github.com/ardalis/ApiEndpoints shows MediatR is optional

[barnybadzoo]

@maulik-modi , yes i did check the Link..but ApiEndpoints with MediatR reduces complexity compared to the well known MVC pattern. Of course you can have both. But please check this FAQ: https://github.com/dotnet-architecture/eShopOnWeb/wiki/Frequently-Asked-Questions where Microsoft shows for both an example (OrderController and ManageController). From my point of view ApiEndpoint with MediatR is much simpler and groups everything that has to do with a particular API endpoint together.

[maulik-modi]

@barnybadzoo , there are 3 choices - 1) Use controller - NO MediatR - ManageController 2) Use controller + MediatR - OrderController 3) Use ApiEndpoints - NO controller, NO MediatR - https://github.com/ardalis/ApiEndpoints

I am referring to 3)

[xNarkon]

Any update? What about intermodular communication using the CQRS pattern? Currently, there is no possibility to get some resources from another module in the monolith architecture but there are clear needs sometimes to fetch some data. In the microservices architecture, this is typically normal and there are possibilities to do that, using REST API / Query Bus, etc. But using modules and building modular monolith using ready-to-use components there is no possibility to easily do that without introducing coupling

[yangfan-zz]

Simple implementation of abp cqrs, using MediatR Fan.Abp.Cqrs

[appsupport-gc]

I found it fairly simple to use the nuget package FS.Abp.MediatR.Domain and use normal MediatR Logic.

In SomeDomainModule.cs: public override void ConfigureServices(ServiceConfigurationContext context) { context.Services.AddAbpMediatR<SomeDomainModule>(); }

public class CreateSomethingCommand : IRequest<Something> { ..... {

public class CreateSomethingCommandHandler : IRequestHandler<CreateSomethingCommand, Something> { async Task<Something> IRequestHandler<CreateSomethingCommand, Something>.Handle(CreateSomethingCommand request, CancellationToken cancellationToken) { return new Something(); } }

To call inject IMediator mediator and then call mediator.Send(new CreateSomethingCommand([arguments])

It would be nice if there was an officially supported Volo.Abp.MediatR.Domain nuget package

[adam-dot-cohen]

Any updates on this?

[johnnypea]

I would be interested in seeing this in action as well. Any pointers?

[sponge1220]

Hi, any updates on this issue?

[hikalkan]

No, this is not planned yet. To be honest, we don't think that we can invest our time on that in a short time.

Actually, we would like to hear from the community about their experiences on implementing CQRS in their ABP based solutions. We want to learn what is the problem of using existing CQRS libraries in your ABP solutions. Please write to us about your experiences.

[sponge1220]

Understood. In reality, I haven't used any CQRS package or methods on ABP before.

The reason ABP team wants to implement this is to have an officially designed solution to reduce trial and error.

However, it sounds like this might not happen quickly, so I'll try using CQRS on ABP and provide feedback or contributions.

[hikalkan]

To be honest, our team has no expertise on CQRS implementation in real world scenarios. We are mostly in theorical side. So, it would be good to know experience from community (comments, articles, draft integrations, etc) before we deep dive that topic. After all, this is a community driven project :)

[aelhadi]

Some disadvantages of Event Sourcing with CQRS are:

It can be complex to implement and maintain It can require more disk space and memory than traditional data stores It can have longer bootup times after failures or upgrades. It can lead to eventual consistency issues in some applications. It can be challenging to handle entities with long and complex lifespans

I'm not fun of CQRS, it's a waste of time in my opinion ;-) a lot of complexity for nothing...

[adam-dot-cohen]

CQRS adds complexity as aptly put by @aelhadi. But the complexity of CQRS offers substantial ROI that increases as a function of the scale - and the inherent complexity that comes with it.

If we consider all of the points made by @aelhadi, they apply to all distributed system architectures - especially microservices which add an array items to @aelhadi's CQRS list above. My personal favorite is the art of partitioning the problem domain (reminds me of Zen and the Art of Motorcycle Maintenance) - and the data integrity and eventual consistency problems that follow.

ABP's microservice implementation is a good example. Breaking your system into pieces across domain and network boundaries equates to more things to maintain, more resources to utilize, more things to fail, more data to synchronize - and the path to precision analytics and business intelligence can be a long road...in some cases to nowhere.

In my opinion, any attempt to implement CQRS on top ABP framework's existing architecture is a fools errand. On the other hand, an in process mediator with decoupled decorator support such as MediatR - would add substantial value in the form of collapsing the project system (9+ projects is a bit much), decoupling the kitchen sink of dependencies, and providing extensibility w/o the headache of modules (and the 9 additional projects per module).