So I started reading about Clean Architecture, and so far I can see that the whole purpose of an architectural design like this is to separate concerns, parts of the application in order to make bigger future changes like switching to a different ORM easier.
From the articles I've read, it seems like the WebAPI project of the solution should have a reference to the Application and Infrastructure layers. I get why we need a reference to the Application layer, but what about Infrastructure?
This is making the WebAPI layer, which is essentially the entry point of the application, depend on the Infrastructure layer, which leads to a tightly coupled situation (at least in my head)
Can you please help me understand the reason behind this? What happens if you make changes to the infrastructure layer. In this case it would possibly break the whole application, because the entry point is broken, wouldn't it?
CodePudding user response：
By general rule of thumb, all of the registration of the modules (not services) is done in the presentation layer.
For example:
// Add services to the container.
builder.Services.AddApplicationServices();
builder.Services.AddInfrastructureServices(builder.Configuration);
builder.Services.AddWebUIServices();
This is done because the presentation has its own extra layers, like logging, configuration, error handling and more that should be registered in the presentation layer because it depends on the asp framework itself rather than any other third party libraries.
So technically you don't want your infrastructure to be dependant on the fact that its an asp dotnet core project and thats why we try to register the framework related things inside of the presentation layer.
If you really want to you can make it so the infrastructure is registered in the application service registration and that is fine but it kills the whole idea that all the modules would be registered in one single place.
Additionally, you sometimes have infrastructure implementations that are only dependant on the web api itself. For example, lets say you have an interface called ICurrentUserService, one of its implementations would be HttpCurrentUserService when you are sending a request and this service would be in the presentation layer because IHttpContextAccessor is only registered on the presentation layer. Alternatively you can have a different implementation of the service when you aren't coming from an HTTP request and that service would be registered in the infrastructure layer.
Here is an example of this service I am talking about:
What happens if you make changes to the infrastructure layer. In this case it would possibly break the whole application, because the entry point is broken, wouldn't it?
Doesn't really make sense, if the infrastructure won't compile obviously the project doesn't work. The infrastructure only holds implementation and if some of these implementations are broken it doesn't mean the whole app dies.