C#•2y ago

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:

Controllers
Application
Domain
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?

jcotton42•1/30/24, 9:04 PM

this is the fatal flaw of CA, you have to do weird contortions and throw away useful features of your libraries and frameworks in order to cram your app into CA
this is why I lean towards vertical slices, but it sounds like you're locked into CA?

TYoemtais.zOP•1/30/24, 9:15 PM

Yep, but I'm just trying to divide the domain into such parts that relate to the functionality, a little bit like in VS. But what pains me the most is the possible abandonment of EF entity tracking. It seems to me that I will have to spend a lot of time on it for something that is unlikely to occur.
That's why I wanted to ask experienced C# programmers. I have a lot of experience in the front end, where just everything was modular.

jcotton42•1/30/24, 9:37 PM

$vsa for context

Jjcotton42 $vsa for context

MODiX•1/30/24, 9:37 PM

https://www.youtube.com/watch?v=T-EwN9UqRwE
https://codeopinion.com/restructuring-to-a-vertical-slice-architecture/

TYoemtais.zOP•1/30/24, 10:06 PM

@jcotton42 could you tell me what is your opinion about adding mapping to additional model? Besides vsa

jcotton42•1/30/24, 10:06 PM

wdym?

TYoemtais.zOP•1/30/24, 10:10 PM

I mean the main question I included in the main post. That is, in a nutshell, is it wrong to work directly on entities and you need to map them first to models that do not have a link to the repo.

jcotton42•1/30/24, 10:10 PM

so, generally you don't want your EF entities to leak, because you can get bitten if someone decides to modify it while the change tracker is still active

jcotton42•1/30/24, 10:11 PM

keep modifications local, and use DTOs for data in and out

TYoemtais.zOP•1/30/24, 10:12 PM

Ok, thanks!

jcotton42•1/30/24, 10:14 PM

also using DTOs protects you against things like overposting, sending too much info back to the user, etc.

TYoemtais.zOP•1/30/24, 11:12 PM

I use DTOs when it comes to external communication. Only I feel that creating an additional domain model just to keep it "clean" is time consuming and problematic. In case my domain is 1 to 1 with the database anyway, using EF entities is great. I can save a lot of time.
EF keeping track of changes is indeed a double-edged sword, on the one hand it greatly simplifies and speeds up the process of writing code, on the other hand you should always remember to save changes only in the main path.
And yes, this could cause a problem someday that you would have to spend time on, and separating the data model and the domain model would help.
But in such situations, don't we forget how much time and effort we have saved?
I have a big headache when it comes to this, on the Internet I come across different opinions when it comes to EF entities as a domain.

TYoemtais.zOP•1/30/24, 11:17 PM

I probably have a big bias when it comes to this. I'm very comfortable working on entities from EF and it's possible that I'm just looking for confirmation that it's not a bad thing.

dance?•1/31/24, 7:37 AM

i'm trying too to reengineer the architecture from layers to features at work (or at least something that resembles it), it's headaches, especially in the db part