第2章 业务域与技术域的边界定义：业务逻辑隔离、数据抽象层、服务化契约

数据产品架构中，业务域与技术域之间的边界不是一条线，而是一组由业务逻辑隔离、数据抽象层、服务化契约三部分构成的纵深防御体系。这三层边界各自承担不同的职责，又通过数据流、控制流和信任链路形成整体协作，确保业务规则不泄漏到技术实现中，同时技术设施的变更能够被业务层无感吸收。本章从分层、组件职责、流与链路、选型权衡、风险点、落地步骤到验收标准，完整定义这套边界方案。

三大边界概述

2.1 业务逻辑隔离

业务逻辑隔离是距离业务域最近的边界层，职责是将业务规则、领域判断、计算逻辑封装在独立的层中，不允许业务规则下沉到数据访问层或基础设施层。该层通过领域模型和应用服务两个组件完成隔离：领域模型承载核心业务规则与不变量，应用服务编排领域模型完成用例，不包含任何数据存储或网络通信细节。

组件职责清单：

• 领域实体/值对象：封装原子业务规则，保证自身状态一致性
• 领域服务：承载跨实体的业务逻辑，无状态，不依赖基础设施
• 应用服务：编排领域模型，协调事务和安全策略，是业务边界的门面
• 领域事件：业务域内状态变更的显式通知，采用事件总线隔离依赖

2.2 数据抽象层

数据抽象层位于业务逻辑隔离之下，职责是提供统一的、业务语义化的数据访问接口，屏蔽底层存储引擎的差异。该层不包含任何业务规则判断，只关心数据的读写、映射、缓存、事务。典型的实现模式是Repository模式——业务层面向接口编程，数据抽象层提供实现，底层存储的切换完全封装在该层内部。

数据抽象层的核心组件与职责：

• Repository接口：定义业务语义的数据操作方法（如 findByUserId），参数和返回值使用领域对象
• DAO实现：将领域对象映射为数据模型，执行实际的持久化操作
• 数据映射器：处理领域对象与数据模型之间的双向转换，隔离双方变更
• 事务脚本：在数据抽象层边界内管理事务生命周期，不扩散到业务层

// 数据抽象层 Repository 接口示例（Java）
public interface DatasetRepository {
    Dataset findById(DatasetId id);
    Page<Dataset> queryByFilter(FilterCriteria criteria, Pageable pageable);
    void save(Dataset dataset);
    void delete(DatasetId id);
    // 领域语义方法，不暴露任何存储细节
    List<Dataset> findRecentlyUpdated(int days);
}

2.3 服务化契约

服务化契约是业务域与技术域之间的正式协议层，定义了跨进程或跨团队调用的接口规范、数据格式、错误码、版本策略和SLA。契约的核心作用是让调用方（业务域）和被调用方（技术域）各自独立演化，只要双方遵守契约，内部实现可以任意替换。

服务化契约的关键要素：

• 接口定义语言（IDL）：使用OpenAPI、gRPC Proto、Thrift等正式规范描述服务接口
• 数据传输对象（DTO）：专为网络传输设计的扁平化数据结构，与领域对象分离
• 错误码与异常规范：统一的错误表示方式，包含错误码、消息、追踪标识
• 版本策略：向后兼容的版本演进规则（如N-2支持、弃用周期）
• SLA指标：延迟p99、吞吐量、可用性等量化约定

// 服务化契约 Proto 定义示例
service DataProductService {
    // 查询数据集 - 契约版本 v2.1
    rpc QueryDataset (QueryRequest) returns (QueryResponse);
    // 订阅数据变更事件
    rpc SubscribeChange (Subscription) returns (stream ChangeEvent);
}

message QueryRequest {
    string dataset_id = 1;
    FilterExpression filter = 2;
    int32 page_size = 3;       // 业务语义参数
    string page_token = 4;
}

message QueryResponse {
    repeated DatasetRecord records = 1;
    string next_page_token = 2;
    int32 total_count = 3;
}

2.4 三边界的协作与信任链路

三个边界并非独立运行，而是通过数据流、控制流和信任链路相互协作。数据流从上到下（业务域 → 技术域），控制流从下到上（技术域 → 业务域），信任链路贯穿三层，保证每次穿越边界的请求都被验证、审计和可追溯。

2.5 选型权衡

2.6 风险点

• 过度抽象风险：为“将来可能的变化”设计过多的抽象层，导致系统复杂度上升而收益不明显。建议遵循三次重复才抽象的原则。
• 契约膨胀风险：服务化契约随着需求增长不断添加字段和接口，最终变成“大泥球”。需建立契约评审和弃用机制，定期清理过期字段。
• 信任链路断裂：鉴权、审计、版本校验在某个边界被跳过或降级，导致安全漏洞或数据不一致。所有穿越边界的调用必须强制经过信任链路检查。
• 事务边界模糊：业务逻辑隔离层开启事务后，穿越数据抽象层时事务传播行为失控，造成连接泄漏或死锁。需显式定义事务边界与传播策略。

2.7 落地步骤

1. 识别业务域限界上下文：与业务方对齐领域边界，明确哪些逻辑属于业务域，哪些属于技术域。
2. 定义业务逻辑隔离接口：为每个聚合根设计应用服务接口，接口参数和返回值只使用领域对象。
3. 设计数据抽象层契约：根据业务查询需求设计Repository接口，确保每个接口都有明确的业务语义。
4. 制定服务化契约规范：选定IDL（OpenAPI/Proto），定义命名规范、错误码范围、版本策略和SLA模板。
5. 实现信任链路中间件：在服务化契约层实现鉴章、审计日志、版本兼容性校验，并向下传递上下文。
6. 构建边界合规检查：使用ArchUnit或自定义规则引擎，在CI流水线中自动检测边界泄漏（如禁止业务层直接调用DAO）。
7. 灰度验证与调优：选择1~2个核心数据产品作为试点，收集延迟、变更频率、泄漏次数等指标，调整边界粒度。

2.8 验收标准

• 隔离性验证：任意存储组件（数据库/缓存）的切换不需要修改业务逻辑隔离层和服务化契约层的代码。
• 契约兼容性：服务化契约的向后兼容版本（N-1）能够通过所有已有客户端的集成测试。
• 信任链路覆盖率：所有跨边界调用（进入或离开业务逻辑隔离层、数据抽象层、服务化契约层）都经过了鉴权和审计检查。
• 泄漏检测通过率：ArchUnit或等效工具的边界检查规则在CI中100%通过，无规则被禁用或绕过。
• 变更响应时间：单一业务规则变更的代码修改范围局限在业务逻辑隔离层内，不涉及其他两层。
• 测试分层清晰：单元测试（业务逻辑隔离层）:集成测试（数据抽象层）:契约测试（服务化契约层）的比例维持在 60:25:15 左右。