I have been tasked to set up a guide for a microservice solution structure and find myself reflecting on why exactly I do things the way I do them.
I am struggling to find an answer to the question when exactly I want to add a new project to my solution in a microservice context.
Some Microsoft articles suggest you should do so (see first picture): https://docs.microsoft.com/de-de/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice
while there were discussions going somewhat into detail on this topic already, which have a different result:
https://stackoverflow.com/questions/8678251/what-are-the-benefits-of-multiple-projects-and-one-solution#:~:text=If%20you%20only%20ever%20have,things%20like%20sharing%20source%20files.
It is obvious that you need to organize your code inside a solution. So there are two options: projects and namespaces. The question is: If there is no technical reason to create multiple project files – like reusability across solutions, individual deployment – why not simply organize your code with namespaces in a folder structure in your service project?
The separation of frontend and backend is separated from this. I would create different solutions for frontend and backend, unless its a very small application.
As far as I know DDD is just demanding for a logical separation of application/domain/infrastructure layers. And there is an often undervalued Clean Code Priciple: KISS – Keep it simple, stupid (make it as easy as possible, but not easier).
To be on the same page as to what a solution using multiple projects and a solution using namespaces for those projects is:
Multiple Project Solution:
Ordering.sln
|-Ordering.Infrastructure.csproj
||-MyInfrastructureClass.cs
|-Ordering.Domain.csproj
||-Order.cs
||-OrderItem.cs
|-Ordering.Application.csproj
||-CreateNewOrder.cs
|-Ordering.Service.csproj
||-Controller
|||-OrderController.cs
|-Ordering.Tests.csproj
Namespace Solution:
Ordering.sln
|-Ordering.Service.csproj
||-Application
|||-CreateNewOrder.cs
||-Controller
|||-OrderController.cs
||-Domain
|||-Order.cs
|||-OrderItem.cs
||-Infrastructure
|||-MyInfrastructureClass.cs
Pro "New Project":
- It forces you to get your dependencies right, as long as you place your classes in the right projects.
- Smaller/Leaner service project
- Assemblies are reusable
Pro Namespaces:
- No need to deploy more Assemblies than necessary
- Smaller/Leaner solution itself
- Less complexity in the solution
The only real benefit of the multi-project solution seems to be that the threshold for messing up dependencies is lower in the namespace solution.
My conclusion so far is:
- The namespace solution is better, if code reviews are done properly to make sure nobody messes up the architecture of the solution.
- Make new projects in the solution only if there is a technical reason for it. Such as reusing an assembly.
So my question is: What do I miss here?
I did quite some research before and found people doing it because of DDD or just to organize their code. From Microsofts code snippets it almost seems like it does not matter. Sometimes its done one way, sometimes another way. But those examples are showing something the article explained, so since the purpose is not to show a good solution structure this may be the reason why.
Best Answer
In case you are talking about having infrastructure and business logic concerns - projects would be preferable.
No need to deploy more Assemblies than necessary
I think this shouldn't matter much, unless you have hundreds of dlls.
Smaller/Leaner solution itself
Solution size would be approximately same - you just replace project folders with namespace folders.
Less complexity in the solution
Hmm, I would say having everything in same project will create more complexity, because now everything can access everything. It will build a ground for effective shortcuts, which lead in more complex and difficult to maintain solution.
The namespace solution is better, if code reviews are done properly to make sure nobody messes up the architecture of the solution
Project structure replaces code reviews to make sure that nobody mess up the architecture :)
Projects provides clear concern separation driven by compiler - you can not have circular dependency.
We can use approach from both "worlds".
Inside same concern project we can have namespaces for different "sub-concerns". For example inside infrastructure project we can have different namespaces for Web and for Database code.
Inside business logic project we can have different namespaces for different domain areas.
Notice that I am talking about two main concerns
Tests would be located in separate project, only because tests have dependencies not required in actual application.