CleanArchitecture VS eShopOnContainers

Looking at this, it has similar aspects as ASP.NET Core, and the same flaws as the Controller per class design used. Methods such as "create", "show" and "store" do not share a state, they shouldn't share a class either.

However, you can rectify this, by just not trying to share a class with any of those. In .NET Steve Smith, aka Ardalis shows how to do this with his Clean architecture idea [1], Idea is to make a class for each endpoint. This also makes it easier for "Update" classes to share functionality with other "Update" classes and so on.

[1]: https://github.com/ardalis/CleanArchitecture/tree/main/sampl...

🔴 [CleanArchitecture] (Learning Template + Docs): A starting point for Clean Architecture with ASP.NET Core. Clean Architecture is just the latest in a series of names for the same loosely-coupled, dependency-inverted architecture.

Here’s a few: - complex domain driven example using vertical slice - another DDD example - clean architecture template by Jason taylor - clean architecture template by ardalis

This repository is a good place to start with modern c# code, specifically ASP.NET

https://github.com/ardalis/CleanArchitecture

If you want to try clean architecture, you can check out Steve smith’s repo or Jason Taylor’s repo.

🔗 Clean Architecture repository | GitHub

Main Repository: github.com/dotnet-architecture/eShopOnContainers

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?