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:
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
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
- 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.