title: Best Practice - Multi Layer Architecture and DTOs
body: <p>After reading some of the Q/As here on stackoverflow, I am still confused about the correct implementation of DTOs in my web application. My current implementation is a (Java EE based) multi-tier architecture (with persistence, service and presentation layer) but with a "common" package used by all layers, containing (amongst others) domain objecs. In this case the layers can not really be considered as independent.
  I am planning to remove the common package step by step, but I encounter various challenges/questions:</p>
  
  <ul>
  <li>Assume the persistence layer would use a class <em>myproject.persistence.domain.UserEntity</em> (a JPA based entity) to store and load data to/from the database. To show data in the view I would provide another class <em>myproject.service.domain.User</em>. Where do I convert them? Would the service for the users be responsible to convert between the two classes? Would this really help to improve the coupling?</li>
  <li>How should the <em>User</em> class look like? Should it contain only getters to be immutable? Wouldn't it be cumbersome for the views to edit existing users (create a new <em>User</em>, use the getters of the existing <em>User</em> object etc.)?</li>
  <li>Should I use the same DTO-classes (<em>User</em>) to send a request to the service to modify an existing user/create a new user or should I implement other classes?</li>
  <li>Wouldn't the presentation layer be very dependent on the service layer by using all the DTOs in <em>myproject.service.domain</em>?</li>
  <li>How to handle my own exceptions? My current approach rethrows most "severe" exceptions until they are handled by the presentation layer (usually they are logged and the user is informed that something went wrong). On the one hand I have the problem that I hava again a shared package. On the other hand I am still not sure that this can be considered "best practice". Any ideas?</li>
  </ul>
  
  <p>Thank you for any answers.</p>