❔ Should I make more transfer classes between layers?
This is also a more general question of whether my architecture makes sense.
I based it on Clean Architecture. (Similar to https://github.com/jasontaylordev/CleanArchitecture)
I have layers:
-Web
-Application
-Infrastructure
-Domain
In domain I have entities declared and domain services / aggregators and validators that deal with business logic.
Entities have very basic business logic, concerning only this entity but most of logic is in services/aggregators.
In application I have commands and queries where I call methods from the domain and eventually map to a DTO that comes out to web.
In application I also receive domain events to, for example, log what happened.
However, I have a problem. Suppose I have a class Car. To it I have a carService that, using the repository, adds, edits or retrieves cars.
And the method is, for example, _carService.UpdateCar(id, name, color, ... 10 more props) or identical _carService.AddCar(name, color, ... 10 more)
I would like to call this in a handler in the application, but passing so many parameters does not appeal to me. What is the best approach? Should I make another transfer class between the application and domain layer?
I was thinking to maybe creating record for such methods, that will act as transfer model for data.
But maybe I should create additional CarEntity, that will only act as transfer from/to DB?
The application will be large and developed over the years. Currently it contains more than 50 different types of entities.
Does my architecture more or less make sense?
6 Replies
application connects web and domain, so i wouldn't create a specific model for the layer per se
but if a specific feature requires a its slice of domain mapped from another feature then sure why not
So it's better to move DTOs to Domain, and also use it when sending data from application to domain?
There are points, what I think are against that:
Domain Purity: Clean Architecture principles emphasize that the domain shouldn't be aware of external details.
Volatility: DTOs, influenced by UI or external system requirements, might change frequently. Incorporating them into the domain could lead to undesired frequent domain modifications.
Added Responsibility: The domain layer should focus on business logic.
So it's better to move DTOs to Domain, and also use it when sending data from application to domain?what, no, why would you do that
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.I'm just thinking how to pass many params of object to Domain from Application.
I'm not using new Entity() in Application, also I don't update entity in Application, I just pass data to Domain, where I do most of logic.
And you said you "wouldn't create a specific model for the layer per se" so I thought about that
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.