Specification VS eShopOnContainers

If so, then look into this

Also, to minimize duplication of code and optimize your architecture i suggest using something like https://github.com/ardalis/Specification

This is a great candidate project for the Ardalis.Specifications library.

This is honestly such an amazing way to make sure you have a clear view of what your Linq does, see https://github.com/ardalis/Specification - note that the examples on the front git page uses a repository, but he later allowed the use directly on DbSet which finally made it possible for me to use the library.

Check out the specification pattern - it is designed to encapsulate query logic similar to your example. Steve Smith has a nice library for it on GitHub: https://github.com/ardalis/Specification

I'm thinking that the only way to abstract both of them would be to have the repositories return IEnumerables and have well defined aggregates for the entire application to avoid an exploding number of methods on the interface, but this is not possible in my project*. I've looked at Steve Smith's Specification library, but since it works with IQueryable, it would not work with Dapper.

The eShopOnContainers is pretty popular, have you seen it yet? https://github.com/dotnet-architecture/eShopOnContainers

so I was exploring eShopOnContainers a little bit, more specifically the messages queues part and it made me wonder how is it possible to ensure data consistency across microservices when using them. If I'm not mistaken this isn't even shown in the eShopOnContainers examples.

For an example of an aggregate if you're unfamiliar - https://github.com/dotnet-architecture/eShopOnContainers/blob/3169a933447f1013c069e2cad2805c5de1ce9fbf/src/Services/Ordering/Ordering.Domain/AggregatesModel/OrderAggregate/Order.cs

You can check out eShopOnContainers as a reference architecture if you want, but (assuming this is meant to be somewhat of an ad hoc solution rather than a paragon of software engineering) I'd minimize the number of deployable assemblies (1 + tests if possible) and avoid Docker, again unless you have a specific reason to use it.

For K8s, it has a whole directory with deployment scripts. https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/deploy/k8s

Checked the eshop on containers which uses EF for writes with DDD. Queries uses Dapper with raw sql. https://github.com/dotnet-architecture/eShopOnContainers/blob/dev/src/Services/Ordering/Ordering.API/Application/Queries/OrderQueries.cs

Maybe Microsoft’s eShopOnContainers reference system?