✅ CQRS and Repository pattern
The repository and services pattern is very similar to the mediator and CQRS. What's the point of these two similar patterns?
1 Reply
oh gosh, this is an interesting question...
* repository - abstracting how to connect to a data store, usually a database
* service - abstracting the business logic, which relies on a data store
i will say that i prefer not to use repositories at all, because i believe that database queries are business logic as much as the rest of the code, and because i don't believe that the abstraction of a data store is very often relevant. in most cases, the data store is something that will not change over the lifetime of the application, or when it does, the level of testing necessary for confident switching is roughly equivalent with or without the abstraction. as such, i skip repository pattern entirely, and just use services directly.
* mediator - i make the argument that libraries like
MediatR, Mediator, and Immediate.Handlers do not actually implement the mediator pattern. the mediator pattern is about connecting and adapting data between multiple sources. instead, the first two implement the "command-dispatch" pattern, and the last one is primarily focused more on aspect-oriented programming in the form of a "command-dispatch".
* CQRS - a specific use of the command-dispatch pattern with an emphasis on classifying and separating different types of commands: "queries" and "commands" (yes, a reuse of the word; in context, it makes sense though). a "query" is a command that is read-only, and will only ever retrieve data; a "command" is a command that is read-write, and is used to store data (and generally does not return or retrieve it). the purpose then is to live in a state of "eventual consistency", where commands are executed, and then queries are subsequently executed based on the completed command.
feel free to ask follow-up questions - i'm sure this does not answer your curiosity completely.