Optimizing .NET core microservice project structure-CodePudding

I trying to develop Microservice in .Net core. planning to implement project structure like

Frontend
Services
 -Product
   -Product.Api
   -Product.Application
   -Product.Domain
   -Product.Infrastructure

 -Basket
   -Basket.Api
   -Basket.Application
   -Basket.Domain
   -Basket.Infrastructure

 -Order
   -Order.Api
   -Order.Application
   -Order.Domain
   -Order.Infrastructure

In the above project structure, under service folder currently three module(Product, Basket and Order). many module will added later.

Where each module have 4 projects for Api, Application ,Domain, Infrastructure. if add more module increase number of class library and web project. this will drop Visual studio loading, compile and running time of project due to my hardware is not enough.

Please recommend any other pattern for optimizing number of projects in the microservice?

CodePudding user response：

If the number of class libraries is the determining factor in your architecture performance, maybe it is time to converge the modules into the same module.

If it is absolutely necessary to continue using the microservice architecture and the high number of modules, you should consider investing in more powerful hardware.

Developing software often requires a lot of ram to house all the processes running the stack locally.

Another approach would be to try to develop on a cloud platform such as Azure, and use the corresponding tools to debug against a cloud instance.

CodePudding user response：

well, I have some notes on this Architecture you are making. if you do it right the one of the payoff is going to be less impact on the hardware.

note#1 : make A Kernel Module which has all of the abstraction of the common functionalities. (that other microservices and take a reference from). like the base repository, message queue base handler ,command /command handler. and u you want to disconnect a module from the kernel you can do that and add your own abstractions alone in that module (simplicity is the ultimate sophistication).

note#2 : Not every module needs to have the same projects or layers as u putting for example: -generally speaking- Basket doesn't need infrastructure. all it does to tell the order module if there is any order on going or pending for this user.

note#3 : microservices is notorious of needing a high-end server to handle the massive amount of nodes/application.

finally I have an awesome blueprint for you to study and follow. which happens to covers the same case youre after.

here is the link

CodePudding user response：

Like @abo said: if the number of assemblies in impacting the performance of your application consider one assembly per module.

If your driver for having multiple assemblies per module was governance on dependencies then consider using an additional tool like https://github.com/realvizu/NsDepCop which allows you to enforce architectural/dependency rules without the help of the compiler.

CodePudding user response：

If Product, Basket and Order are different microservices, then they should be in different Visual Studio solutions. Each solution will be small and independent and they'll all load and work fast regardless of how many microservices you have.

If Product, Basket and Order are part of the same microservice and you are planning to add many more modules, your microservice design is probably wrong, as a single microservice appears to have far too many responsibilities. In this case, the solution is to limit the responsibilities of each microservice so that they don't grow to enormous sizes.

If what you are building is a modular monolith (a single deployable unit, but with the code organised in modules), then the solutions are a bit different. If it's a single developer application, you probably don't need to split the modules in separate projects. For example, the whole API can be a single project and each module be in a different folder. If there'll be many developers and teams working on the source code, then you might want to create a separate solution for each module, so each team can work on their own code.