控制你的DTO数据结构

文中的想法最适用于实现（复杂）业务规则、状态转换并将其数据保存到某个数据库的后端应用程序。

复杂的逻辑应该在您可以完全控制内部域模型的数据结构上实现，您可以根据问题对其进行定制以简化代码。

这是本文中使用的术语定义的（自以为是的）列表：

• 领域= 要保留应用程序逻辑中最复杂部分的代码区域。任何 架构 的目标都是清理实现系统基本复杂性的环境。
• 数据传输对象 (DTO)  = 跨系统边界移动的对象，例如，编组为 JSON、XML 或二进制格式。
• API = 系统的入口点（REST 端点或消息队列）以及所涉及的 DTO。许多系统都暴露了一个 REST API，然后依次调用其他系统的 API。
• 领域对象 （例如，值对象、实体、聚合）= 应用程序的内部数据结构，通常保存在某些数据库中，但在系统外部不可见

避免 DTO 的原因

• DTO 臃肿

由 第三方方 API 公开的大多数 DTO 更通用，并且包含的​​字段比您在应用程序中需要的属性子集更多。理解一种称为采用包含 3 个字段的对象的方法比采用具有 12 个字段（加上 2 个子列表）的参数的方法要容易得多。

• DTO 扁平

设计 API 的一个关键问题是向后兼容性，也就是说，当 API 明天发生变化时，不会破坏现有的客户端。

很多时候 DTO 是扁平的，很容易退化为具有几十个属性的结构。另一方面，我们更喜欢在我们的领域中使用更小的结构&#