dotnet-architecture
Project structure of eShopOnContainers suitable for real project
I'm completely new to microservice. When I checking this project . Everything available for the Microservice such as gateway, services and web in single solution. But individual domain suppose Basket , which is simple project it's only have one class project Basket.API.csproj . There is no other class library for Repository or domain . every thing in single project with folder structure instead of multiple class library.
But in real world project we have to adapt DDD , Clean architecture ,CQRS or simple Repository pattern with multiple project(Class library).
For Example
above project different layer in DDD. But eShopOnContainers project have single project with every thing structured in folder manner. Suppose we follow DDD in every Domain (Basket , Shipping, etc.) with different cs project it will be a huge solution.
This project suitable for real project or it's just for learning purpose?
I'm curious where you're getting your "DDD" folder structure from?
I copied from one DDD project. https://github.com/ntxinh/AspNetCore-DDD Come to microservice Eric Evans also recemented to use DDD. suppose we adapt this DDD project structure will be very huge.
I'm new too, so i just have only some thoughts about the topic, not real knowledge, but i think it is interesting to discuss. So as i see it, your structure is for monolith back-end, which is supposed to be like template for big scale application, properly divided into projects for better cooperative developing, testing etc.. In the case of microservices, and particularly eShopOnContainers solution, you already have some of this design blocks separated as different microservices, like Identity, Bus, etc.. Then, after you divide REST API into domain parts (which is essential application of DDD to MSA), you are free to design and implement each corresponding microservice the way it better suits its needs. For example Basket.API is very lightweight service that doesn't even uses sql db (only Redis). So at this point no need to extra complicate its structure (but you absolutely can refactor it if you want to grow it bigger). If you check Ordering.API it has all you mention as many projects for different layers. As your concern about "huge solution", yes, it will be huge, cause microservices are huge, it is pretty big step into architecture complexity increase, there are totally gain/loss trades with it, as i can see. As for real/learning project, I'm on the side of, if it works, it is real project. But the purpose it works for as is, is learning. If you have another purpose, another goals, conditions, and restrictions, you need to modify it, refactor, redesign, re-architect or remove and replace, according to them.
Hi Hadsen, Initially I leaning Microservice, I thought this is perfect project for microservice. Then I start to implement microservice not fit properly.
In real world Microservice each Module or Domain(Product ,Shipping) may developing different team with different technologies. Individual team can adapt different architecture depend on scenario such as DDD, BDD ,N-tier.
Most of application I worked with N-tier or 3-tier. where clear grouping Every thing in logical manner. it's also separate Class Library for each tier.
For Example (Not perfect sample)
- Basket .Frontend
- Basket .BusinessLogic
- Basket .Backend
This Basket project designed like
In this project keep every thing under WEB API in folder structure . Repository kept under infrastructure folder. no separate Class library.
My question is this coding standard is perfect for real world project?
Hi @Shij0, This is just a demonstration of how to implement microservices, it is not production-ready. For illustrations of the implementation of an e-commerce application, you can visit the learning module: https://docs.microsoft.com/en-us/learn/paths/create-microservices-with-dotnet. I am closing this issue, however, feel free to continue the conversation or reopen it if you are looking for more help.
