Microsoft states that the CQRS pattern isn't recommended in situations where the domain or the business rules are simple

[VictorioBerra]

I am not sure if that app is the best real-world example of a ASP.NET Core app.

Microsoft states that this pattern isn't recommended in situations where the domain or the business rules are simple, a simple CRUD-style user interface and the related data access operations are sufficient and/or for implementation across the whole system.

There are specific components of an overall data management scenario where CQRS can be useful, but it can add considerable and unnecessary complexity when it isn't required."

• https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs

[adamhathcock]

Microsoft guidance isn't the gospel truth. There's a wide community of .NET developers that explore things outside of the Microsoft box. CQRS doesn't mean anything other than having separate pathways for commands vs queries. There is usually a big distinction in what they do.

If you're looking for a Repository pattern with horizontal layers and unnecessary duplication then this isn't it. The vertical slices for operations allows for a more concise code base. If complexity grows then refactoring can group functionality and common code together.

The references on the README try to explain further.

[VictorioBerra]

I have spent the last few days pouring over all articles on the README, articles related to Onion architecture, building my own prototype apps to learn some nuances of each and I can see both having their own place.

horizontal layers and unnecessary duplication

The repository pattern allows you nice isolation of your business logic in your services for test-ability. Anyone who has ever had to talk to SQL, Hbase, and Dynamo will tell you that they are probably thankful all they had to do was re-write their repository layer. All that to say I think each pattern really depends on your use-case and the complexity of your application.

I think this RealWorld repository is inherently flawed in the fact that it says "this is the best way to solve all problems". I like the showcase of things like adding Swagger, using cors, what libraries to use and how to abstract certain things away. Also popular libraries like these tend to get some experienced eyes on them which always makes me feel better when I read and use examples from code that I know has been proofed before. Even though I have recently added an issue about a lack of comments in this code base.

My original comment was just to warn people that this library uses a very opinionated pattern of problem solving and that its not the hammer for all nails.

[adamhathcock]

The repository pattern allows you nice isolation of your business logic in your services for test-ability. Anyone who has ever had to talk to SQL, Hbase, and Dynamo will tell you that they are probably thankful all they had to do was re-write their repository layer. All that to say I think each pattern really depends on your use-case and the complexity of your application.

Repostory doesn't give you anything but an unneeded layer of abstraction when what you want is something specific like the Query classes do. A quick google for repository anti pattern finds a lot: https://www.infoworld.com/article/3117713/application-development/design-patterns-that-i-often-avoid-repository-pattern.html

This definitely does not say "best way to solve all problems" but it is a demo of more modern practices than things like the Repository pattern. It is definitely not a one-size-fits-all.

Every strategy is opinionated and tries to guide users down a path. Everything should be examined. As I've said, this is a demo of where a lot of the mindshare of some things that the community does outside of the Microsoft sanctioned practices.