MediatR is a tool - and just like any tool, it has its own scope of application, and being used incorrectly might do more harm than good. This blog post summarizes my thoughts about using MediatR for supporting CQRS architecture.

W CQRS często definiuje się interfejsy dla handlerów, aby wymusić ujednoliconą strukturę kodu. Takie podejście stosowane jest m.in. przez bibliotekę MediatR. Nawet jeśli nie używasz żadnych bibliotek, ale ręcznie dziergasz swoje rozwiązania, możesz chcieć iść tą drogą. W moim najnowszym artykule wyjaśniłem, jak zarejestrować wszystkie handlery według konwencji za pomocą biblioteki Scrutor.

🚨 Quite often, to make our code simpler, we're trying to make our code more reusable and generic. I wrote an article with a warning that "generic" does not mean "simple". I did that on the example of #CQRS code evolution. Beware and have a read!

Today I would like to show you a really cool way to validate MediatR commands and queries using FluentValidation.

I explained in my recent article the facts and myths of CQRS. If you heard you need: - 2 databases - to use a messaging queue - to be facing Eventual Consistency - use it with Event Sourcing and it's hard to apply and complicates the architecture. Then you should definitely read this post!

Segregacja odpowiedzialności Polecenie-Zapytanie. Te dosłowne tłumaczenie wspaniale opisuje ideę naszego wzorca. Większość z nas jednak wie czym jest CQRS. W końcu temat ten jest poruszany niemal na każdej konferencji! Prezentacje te jednak często nie zawierają przykłady w kodzie, które głównie interesują żądnych technicznych detali programistów.

CQRS is a simple pattern that strictly segregates the responsibility of handling command input into an autonomous system from the responsibility of handling side-effect-free query/read access on the same system. If you are familiar with Domain-Driven Design, you’ve most likely heard about, Command-Query Responsibility Segregation (CQRS). Though the CQRS pattern is well-known, there are still a lot of misconceptions around this pattern, especially when it comes to applying it in real-world software proje...

Gościem występującym w 31 odcinku podcastu jest Andrzej Krzywda, na co dzień programista oraz CEO firmy Arkency. Rozmawiamy o CQRS (Command Query Responsibility Segregation), poruszając najważniejsze podstawy, ale także dyskutując o: CQRSie jako sposobie na walkę z legacy code, szczególnie w kontekście aplikacji opartych o Ruby on Rails, wykorzystaniu widoków bazodanowych w read modelach, czyli „CQRS po białostocku”, dużych formularzach, które mogą wywołać kilka akcji domenowych, Eventual Consistency.

Dziś odpowiedź na zdecydowanie najczęściej zadawane pytanie w kontekście naszego projektu DShop. Brzmi ono „w jaki sposób użytkownik końcowy aplikacji wie czy jego komenda została (i kiedy została) przetworzona?”. Na pierwszy rzut oka odpowiedź na to pytanie może wydawać się trywialna, prawda? Wszak większość typowych aplikacji webowych po wykonaniu jakiejś akcji informuje nas o jej powodzeniu lub błędzie poprzez np. toastry...

Simple .NET Core REST API CQRS implementation with raw SQL and DDD - Kamil Grzybek