Clean architecture and EF entities as domain models
Hi!
I have an architecture inspired mostly by Ardalis's Clean Architecture. It comprises 3 (theoretically 4) layers:
1. Controllers
2. Application
3. Domain
4. Repository (not doing much)
In the Controllers layer, there's primarily the execution of Commands/Queries through a mediator from the Application layer.
The Application layer contains minimal logic, mainly for validations, logging, and operations like sending information via SignalR
In the Domain layer, I have entity-aggregates that maintain a entity(made as rich domain model), interfaces for the repository, and services for each entity, it also includes specifications for data retrieval from the repository. In this layer there are other larger domain services that connect entity-services. They house a significant portion of the business logic that doesn't fit within the entity
I have mapping of entity <-> DTO in the Application layer, skipping the separate mapping from entity to model in domain-repository layer. I've had discussions where it was suggested that an additional layer of mapping from entity to model is crucial, with the idea being that entities should only exist in the Repository layer, while the Domain layer should have its own models.
I see two main issues with this approach. First, my current architecture allows me to fully utilize EF entity tracking, so I don't have to manually track what's changed. Adding another layer would require me to manage lists of added/removed/updated entities, map them, and then commit these changes to the database. This is problematic, especially with highly complex business logic where entities are nested. It seems time-consuming and prone to errors, especially since my entities and models would almost always have 1-to-1 correlation.
Secondly, I understand that an additional layer would be beneficial in the event of database changes. However, such changes would likely necessitate alterations to my models and all the mappings anyway. So, what's the real advantage?
I have an architecture inspired mostly by Ardalis's Clean Architecture. It comprises 3 (theoretically 4) layers:
1. Controllers
2. Application
3. Domain
4. Repository (not doing much)
In the Controllers layer, there's primarily the execution of Commands/Queries through a mediator from the Application layer.
The Application layer contains minimal logic, mainly for validations, logging, and operations like sending information via SignalR
In the Domain layer, I have entity-aggregates that maintain a entity(made as rich domain model), interfaces for the repository, and services for each entity, it also includes specifications for data retrieval from the repository. In this layer there are other larger domain services that connect entity-services. They house a significant portion of the business logic that doesn't fit within the entity
I have mapping of entity <-> DTO in the Application layer, skipping the separate mapping from entity to model in domain-repository layer. I've had discussions where it was suggested that an additional layer of mapping from entity to model is crucial, with the idea being that entities should only exist in the Repository layer, while the Domain layer should have its own models.
I see two main issues with this approach. First, my current architecture allows me to fully utilize EF entity tracking, so I don't have to manually track what's changed. Adding another layer would require me to manage lists of added/removed/updated entities, map them, and then commit these changes to the database. This is problematic, especially with highly complex business logic where entities are nested. It seems time-consuming and prone to errors, especially since my entities and models would almost always have 1-to-1 correlation.
Secondly, I understand that an additional layer would be beneficial in the event of database changes. However, such changes would likely necessitate alterations to my models and all the mappings anyway. So, what's the real advantage?
