Orchard Core VS eShopOnContainers

In open source OrchardCore is ok in terms of project-complexity. When building OrchardCore (AVG 10 runs): https://github.com/OrchardCMS/OrchardCore with $git clean -fdx && dotnet build OrchardCore.sln --force Macbook: Time Elapsed 00:02:13 (AVG 10 runs) Dell: Time Elapsed 00:02:48

While I've been peripherally present in the game industry through my activity here and on GitHub as a Godot contributor, the vast majority of my time as a developer for the past 5 and a half years has been in web development (largely server/database with some frontend) so take that as you will. In that time, I've seen, worked in, and outgrown several project architectures. At this point, I think I've gotten to know the one that works the best, in part because while it has worked for me, it's also the same one that Microsoft employs to maintain its high-profile open-source projects (which are orders of magnitude more complex than anything I've come up with). A good example is the Orchard Core CMS.

Check out orchardcore, the framework not the cms https://github.com/OrchardCMS/OrchardCore it implements multi tenancy pretty easily

The project code is available in the repository on GitHub. We check the code with the PVS-Studio static code analyzer.

If you do want a .NET IdP then you could look into OpenIddict but will require some hands on work, at a minimum authorisation controllers. If you're looking for something more out of the box OrchardCore's OpenId module might be better for you.

As the older roadmap says, it was to be released in 2019. https://github.com/OrchardCMS/OrchardCore/wiki/Roadmap/a4277c874b4f7480c55f02d5a148e4bbb2ff0bcf

Orchard Core Framework (https://github.com/OrchardCMS/OrchardCore/), is a really good technique to implement modularity. Every module is self contained and you can share resources as needed.

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?