我正在设计一个宁静的网络服务，我想知道我应该如何命名我的DTO。我可以使用请求和响应等后缀吗？例如，对于addUser服务，将有2个DTO名为：AddUserRequest和AddUserResponse。
您的组织是否已经拥有描述您传入的规范用户的架构？如果这就是您正在使用的内容，当然您将使用该架构中的名称。否则，就像对任何类或模式元素一样描述它们。
请注意，由于DTO不包含自己的方法，因此您可能不会使用动作动词为其指定名称。
但是，请考虑将它们称为AddUserRequest和AddUserResponse，特别是如果该方法需要的信息多于常规用户DTO。这符合接口隔离原则，因为您的接口参数应该专门针对请求本身定制（它不应该要求与请求无关的元素;并且您不应该具有更改请求的函数类型参数，那些应该将其提取到自己的调用中。）AddUserRequest可能包含一个名为User的元素，用于保存特定于用户的数据，另一个元素包含请求中的其他相关数据集，可能是组或访问权限，这类。
由于它是一个RESTful服务，理想情况下，用户添加/创建请求应该发回201创建的HTTP状态代码，其中userId位于头部标题中且没有响应主体。对于请求，您可以将其命名为UserDetails或UserData，或者仅命名为User。请参阅https://pontus.ullgren.com/view/Return_Location_header_after_resource_creation
DTO（数据传输对象）就像POJO（普通旧Java对象）。它应该只有getters和setters而不是任何业务逻辑。
来自维基百科：
数据传输对象是在进程之间传输数据的对象。其使用的动机是进程之间的通信通常采用远程接口（例如，web服务）来完成，其中每个调用是昂贵的操作。由于每次调用的大部分成本与客户端和服务器之间的往返时间有关，因此减少调用次数的一种方法是使用聚合已传输数据的对象（DTO）通过多次通话，但仅通过一个通话服务。
数据传输对象与业务对象或数据访问对象之间的区别在于DTO除了存储和检索其自己的数据（变更器和访问器）之外没有任何行为。 DTO是简单的对象，不应包含任何需要测试的业务逻辑。
此模式通常在远程接口之外使用不正确。这引发了作者的反应[3]，他重申DTO的全部目的是在昂贵的远程呼叫中转移数据。
因此，理想情况下，您应该创建一些帮助程序，或者可以将它们添加为控制器。