2

I can't wrap my head around what to choose between these 2 flows, in these diagrams I'm using mediator pattern but it does apply to any use-case that has a layer for an interface ( API ) and the application itself ( Domain ).

  • Should I enforce DRY and return the response from the domain directly to the client. But add a separate DTO for incoming requests that is processed by the interface and map it as a domain model.

  • Should I enforce SOC and map all objects coming in and coming out of the domain. One of my major pain points is that adding a new property would require me to update all my objects both on webapi and domain.

I'm curious around what the community currently practices around DTOs on a layered architecture, I've been searching both here and in github repos and most implementations follow the first one ( albeit those were only "sample" projects )

mediatr webapik

enter image description here

dardardardar
  • 314
  • 1
  • 12
  • 3
    It's natural to feel an aversion to having to constantly map between types - especially when sending a response - but that extra mapping insulates your domain, allowing you to safely refactor without breaking clients. If you just return your domain models directly, you lose that. Remember, _public_ != _published_. You should be thinking about the evolvability of your architecture in ways to minimise breaking consumers, and the additional mapping is a step that supports that. – John H Oct 04 '20 at 18:44
  • Adding things isn't usually a problem; clients don't typically go into meltdown if you send them 10 properties when they only coded for 9. Having DTOs isn't necessarily repeating yourself even if there is a 1:1 mapping in some cases – Caius Jard Oct 04 '20 at 18:50
  • Thank for reaffirming me on that. I guess its a good thing automapper exists. – dardardardar Oct 04 '20 at 18:50
  • @CaiusJard my main goal really is to make our devs lives a little bit easier through some standardization. I guess in the long run, maintainability of the project always trumps anything else. – dardardardar Oct 04 '20 at 18:52
  • I think you'l find this interresting: https://stackoverflow.com/questions/23648832/viewmodels-in-mvc-mvvm-separation-of-layers-best-practices – Stefan Oct 04 '20 at 18:52
  • Thanks @Stefan, this is something new i'll look at it. I found something similar earlier this year https://stackoverflow.com/questions/24588838/entities-vs-domain-models-vs-view-models – dardardardar Oct 04 '20 at 18:54
  • 2
    Making a dev's life easier by removing the 10 seconds they need to write `myDto.NewProperty = myDataEntity.SomePropertyIJustAdded` and then click the lightbulb and choose "Generate new string property NewProperty in SomeDTO" probably shouldn't drive a decision :) but perhaps encourage them to think about the roadmap for the product and what you'll want to be doing with it in x months time; add properties or design in such a way now that it can upgrade without drastic shape changes in the future and it makes it easier for customers to integrate. Internally you can rewrite everything if needs – Caius Jard Oct 04 '20 at 18:55
  • @CaiusJard yeah, I guess I was overthinking it. – dardardardar Oct 04 '20 at 18:59

0 Answers0