三层架构中业务层引入OOP对象后的依赖关系解析

核心问题拆解 #

你遇到的本质是领域模型（业务层Delivery）与数据传输/存储模型的耦合问题——如果三层共用同一个Delivery类，会导致业务规则、UI展示逻辑、存储细节混在一个类里，扩展时比如要加UI专用字段或数据库特定字段，都会污染核心业务模型，最终导致依赖失衡。

CRUD Repository是常规解决方案 #

类级别的CRUD Repository绝对是三层架构中数据访问层的标准实现方案，核心作用如下：

• 隔离业务层与数据层的实体细节：业务层只需要定义Repository接口（比如DeliveryRepository），声明所需的业务操作（createDelivery(Delivery businessModel)、getDeliveryById(String id)等）
• 数据层负责实现这个接口，在实现层完成业务模型到数据存储模型的转换：比如数据层可以有自己的DeliveryEntity类对应数据库表，实现类里把业务层的Delivery转成DeliveryEntity再入库，反之亦然。

你的基类思路优化：用数据传输对象（DTO）替代继承 #

你想定义“纯配送数据”基类的思路方向是对的，但继承不是最优解——继承会带来强耦合，而且业务模型和数据模型的变化方向完全不同（业务模型随规则变，数据模型随存储结构变）。更合理的做法是：

• 定义独立的DeliveryDTO：只包含纯数据字段（比如id、地址、状态、时间等），作为层间数据传输的契约
• 业务层的Delivery类依赖这个DTO，同时封装业务逻辑（比如markAsDelivered()、validateAddress()等方法），可以从DTO初始化，也可以导出为DTO
• 数据层的Repository接口基于DTO定义（比如save(DeliveryDTO dto)），数据层内部用自己的DeliveryEntity与数据库交互，在实现中完成DTO和Entity的转换
• 表示层直接使用DTO来展示数据，或者根据需要定义UI专用的DeliveryViewModel，从DTO转换得到

架构扩展的通用依赖原则 #

1. 依赖倒置优先：所有上层（表示层、业务层）只依赖抽象接口，不依赖下层具体实现。比如业务层依赖DeliveryRepository接口，数据层提供实现，而非业务层直接调用数据层的类
2. 实体分层隔离：不同层用不同的实体类：
   • 业务层：领域模型（封装业务逻辑）
   • 数据层：实体模型（映射存储结构）
   • 表示层：视图模型（适配UI展示）
   • 层间用DTO传递纯数据，避免跨层直接依赖实体
3. 单一职责：每个类只做一件事——业务模型只处理业务规则，数据实体只映射存储结构，视图模型只适配UI展示
4. 转换逻辑封装：层间的实体转换逻辑（比如DTO转Entity、DTO转ViewModel）封装在各自的层内：数据层负责DTO和Entity的转换，表示层负责DTO和ViewModel的转换，业务层只关注业务规则

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