Clean Architecture in .Net
Stephan Hoekstra

Thanks a lot for that great post!

I still have one question: comparing with OnionArchitecture, Entities here seems not to be allowed to be crossed the borders. So you used DTO´s objects instead, as input and output for the use case. In the Dependency Rule from Uncle Bob it is said, that dependency´s must always point to inner circle(s!). As I remember, it was NOT SAID that only the next neigboured circle is allowed for a dependency! So in my opinion, the dependency rule is not violated, if any outer circle is accessing the most inner cirlcy (entity), like in the OnionArchitecture.

Confusingly he wrote in his book another sentence where he said that it would be “cheating” if entity´s are crossing the borders… weired^^, that is inconsistant with the dependency rule he specified! I whish he would make this more clear.

I am asking because I think using alway´s DTO´s for every use case makes the application quite expensive, slow and more complicated (violating KISS-principle). DTO´s should better be used for external access (as a stable facade) I think, e.g. as an Gateway for external access, but not for internal usage.

Example: if I have a RESTful WebAPI controller, transforming the domain entity automaticly into/from JSON objects being consumed by an Angular app, it makes for me no sense to make an additional transformation into a DTO based on the JSON in the controller for calling the use case (multiple transformations/mappings: JSON-object -> DTO-object -> Entity-object). Why not working directly with the domain entity in the WebAPI controller?

What do you think about? What do I not see what Uncle Bob wantet to explain? Or maybe Uncle Bob mean something else by saying it would be “cheating” if entity´s are crossing the borders?

Thank you!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.