基于Clean Architecture的移动端前后端领域实体模型定义最佳实践咨询

Clean Architecture的核心原则是领域层（业务核心）独立于所有外部层（UI、基础设施、第三方服务），所以前后端实体模型的定义，本质是围绕「业务核心所在位置」展开，而非简单的谁主导谁。以下针对你提到的两种场景逐一说明：

场景1：核心业务逻辑在移动端，后端仅做存储/通信 #

这类场景中，移动端是业务规则的承载者（比如待办事项的状态校验、本地操作逻辑），后端仅作为远程数据同步的通道和存储载体。

• 核心实体定义：在移动端的领域层定义纯领域实体，只包含业务规则（例如TodoItem实体包含markAsCompleted()方法，内置“已完成的任务无法修改”的规则），完全不涉及UI展示、后端API格式等细节。
• 后端侧处理：后端无需定义领域实体，只需要定义数据传输对象(DTO)，结构适配移动端领域实体的持久化需求即可。后端不承载任何业务逻辑，仅负责存储和同步DTO数据，不需要理解字段的业务含义。
• 错误做法：让后端主导实体结构，会导致移动端的业务逻辑被迫适配后端存储格式，违反Clean Architecture“领域层独立”的原则。

场景2：核心业务逻辑在后端，移动端仅做GUI #

这类场景中，后端是业务规则的核心（比如协作任务的权限校验、多用户状态同步逻辑），移动端仅负责界面展示和用户交互。

• 核心实体定义：在后端的领域层定义纯领域实体，包含所有业务规则（例如CollabTask实体包含assignToUser()方法，内置“仅管理员可分配任务”的规则）。
• 移动端侧处理：移动端无需定义领域实体，只需要定义UI模型，结构适配界面展示需求即可。比如后端领域实体包含createdTimestamp、assigneeId等业务字段，移动端的UI模型可以转换成创建时间：3天前、负责人：张三这类更友好的展示格式，甚至可以裁剪掉不需要展示的字段。
• 错误做法：直接把后端返回的DTO当作移动端的业务模型使用，会导致移动端耦合后端的业务结构，无法独立优化UI交互逻辑。

对几种思考方向的判断 #

• 「前端/后端单方面主导」：仅当业务核心完全在某一端时适用，但要区分领域实体和适配层模型——主导的是领域实体的定义，而非所有数据模型，另一端只需定义适配自身职责的模型。
• 「前后端采用同一实体模型」：不推荐。前后端职责不同，同一模型会导致业务逻辑被UI或存储细节污染，违反Clean Architecture的依赖规则。
• 「前后端分别定义独立实体模型」：如果是指两端的适配层模型（后端DTO、移动端UI模型）独立，这是推荐的；但如果是指两端都定义各自的领域实体，仅适用于两端存在独立业务核心的极端场景，大部分情况不需要。

具体实现步骤 #

1. 定位业务核心：先明确核心业务逻辑在哪一端，以此为中心定义纯领域实体。
2. 隔离适配层：两端各自定义适配层模型（DTO/UI模型），用于在领域实体和外部（API/UI）之间做数据转换。
3. 实现转换逻辑：在各自的适配层完成转换，比如移动端用TodoRepository把领域实体转换成后端DTO，后端用TaskController把领域实体转换成前端UI模型。
4. 禁止跨层耦合：领域实体中不能包含任何适配层的代码（比如序列化注解、UI相关字段），确保领域层的独立性。

内容的提问来源于stack exchange，提问作者wurikiji