知识卡片
DTO按需定义，避免臃肿暴露后端逻辑，多渠道可各自定制
内容
DTO的字段设计不应该图省事直接照搬DO的全部属性，而应严格按照前端实际展示需求按需定义——一个DTO包含的属性越多，越容易把后端的业务结构和数据逻辑不必要地暴露给前端消费方，也让DTO和DO之间的转换维护成本变高。对于同一段核心业务逻辑（同一个应用服务或领域服务）需要同时服务PC端、移动端等多个不同渠道前端的场景，不必强行让所有渠道共用一套DTO和facade接口，而是可以按各渠道的数据和接口要求，把同一个DO分别转换成不同的DTO、把同一个应用服务分别封装成不同的facade服务。这样做的关键收益是：前端接口和数据格式可以随渠道需求灵活变化，而后端核心业务逻辑代码完全不用因此改动，实现了核心领域逻辑稳定性与前端多样化需求之间的解耦，这也是[[用户接口层的facade与Assembler让核心逻辑对多端差异保持稳定]]这一设计目标在DTO粒度上的具体落地方式。
参考来源
- 位置：第19章《基于DDD的微服务代码详解》"19.8.2 DTO数据组装"（源文件：_epub-src/OEBPS/Text/chapter4-8-8-2.xhtml）
- 结论依据：原文说明"DTO属性应尽量根据前端数据展示需求按需定义，避免DTO一次包含属性过多，暴露后端业务和数据逻辑……对于同一段后端核心业务逻辑……在面向多个不同渠道应用……提供服务时，如果需要根据不同的前端应用需求，提供不同的接口和数据服务，我们可以根据不同前端的数据要求将DO转换为适配不同前端应用的DTO，根据不同前端的接口需求将同一个应用服务封装成不同的facade服务"，直接支撑本卡片结论。
- 原始内容：DTO属性应尽量根据前端数据展示需求按需定义，避免DTO一次包含属性过多，暴露后端业务和数据逻辑。尤其对于多渠道应用场景，可以根据渠道属性和数据以及接口要求，按需为不同的渠道前端应用定义个性化的DTO和facade接口。