Day29-02｜7.5.2 DSSA 的基本活动：从领域分析到应用实例化

一、教材定位

上一节学习了 DSSA 的定义，本节进一步回答：一套 DSSA 是怎样建立起来的？它不是先画一张漂亮的架构图，再要求所有项目照着实现，而是通过一组连续活动，把领域知识转化为领域模型、参考需求、参考架构和可复用资产。教材通常将 DSSA 的基本活动概括为领域分析、领域设计和领域实现；在实际项目中，还需要把这些活动与应用工程的需求确认、架构实例化、构件组装和验证连接起来。

二、DSSA 活动总览

领域范围与资料收集 ↓ 领域分析：发现共性、可变性和领域约束 ↓ 领域设计：形成 DSSA、参考架构和领域模型 ↓ 领域实现：开发可复用构件、框架和资产 ↓ 应用实例化：选择变体、配置组装、定制开发 ↓ 验证反馈：测试应用并反哺领域资产

领域活动面向“多个应用的共同基础”，应用实例化面向“某个具体系统的落地”。二者之间不是一次性单向关系。应用项目遇到的新需求可能说明领域模型需要扩展，某个项目中反复出现的适配逻辑可能应该上升为新的领域资产。因此 DSSA 建设是一个持续演进的闭环。

三、第一项基本活动：领域分析

领域分析是从问题域出发，识别领域范围、领域概念、业务流程、共性需求、变化需求和领域约束的活动。它的输入包括已有系统、业务规范、标准、用户访谈、需求文档、故障记录、接口资料和行业知识；输出包括领域范围说明、领域术语表、领域模型、参考需求、共性分析结果和可变性模型。

1. 确定领域边界

领域边界决定哪些内容纳入 DSSA，哪些内容留给具体应用。确定边界时要考虑业务流程的完整性、产品线的相似性、组织职责、数据所有权和复用规模。例如“交通系统”过于宽泛，可以进一步限定为“城市公交调度系统”；“政务系统”也可以限定为“面向多个部门的行政审批系统”。边界要能让领域内应用共享足够多的知识，同时避免把差异巨大、变化频繁的业务强行统一。

2. 建立领域词汇

不同项目对同一概念的称呼可能不同，领域分析需要建立统一术语表。例如在物流领域，“货物到达仓库”“入库”“收货确认”可能分别来自不同团队，但架构师要明确它们是否是同一个业务事实。术语统一能够减少接口字段歧义，也能帮助识别哪些概念是真正的领域共性。

3. 识别共性和可变性

共性分析应覆盖功能、数据、交互、质量属性和运维能力。可变性分析应记录变化点、变化范围、变化原因、变化频率和承载方式。例如所有订单系统都有下单和查询，但支付渠道、价格规则、库存策略和配送流程可能变化。架构师不能只列出“共性功能”，还要识别跨应用稳定的质量要求，如审计、权限、可追踪性和故障恢复。

四、第二项基本活动：领域设计

领域设计把领域分析结果转化为 DSSA。输出包括参考架构、领域模型、子系统划分、领域构件、接口契约、可变点设计、质量属性策略和架构约束。

1. 设计参考架构

参考架构应至少说明逻辑视图、开发视图、数据视图、部署视图和运行场景。逻辑视图说明领域子系统和职责；开发视图说明模块、组件和依赖；数据视图说明主数据、事务边界和数据所有权；部署视图说明节点、网络、容灾和扩展方式；运行场景说明请求、事件和异常如何流动。

2. 设计领域构件

领域构件不仅是可调用代码，还应包括接口、数据契约、配置、扩展点、测试和文档。领域构件可以分为核心构件、可选构件和适配构件。核心构件承载稳定共性；可选构件根据应用需要组合；适配构件连接不同外部系统。构件之间要通过明确契约协作，避免每个应用直接修改公共构件内部代码。

3. 设计可变点

可变点设计要回答四个问题：变化是什么，谁决定变化，变化何时发生，变化如何验证。配置适合管理员可控制的简单变化；策略和规则适合频繁变化的业务判断；插件适合可独立替换的功能；适配器适合外部协议变化；模板适合流程或页面结构变化。可变点必须有默认值、校验规则、版本管理和回滚方案。

五、第三项基本活动：领域实现

领域实现是将 DSSA 转化为可执行的框架、构件、服务、模板、配置和工程资产。它不等于把所有业务都提前开发完，而是优先实现稳定、通用并值得共享的部分。

领域实现包括：开发领域框架；实现核心构件；定义公共接口和事件；提供构件装配机制；建立自动化测试；编写示例应用；制作部署和监控模板；维护资产版本和依赖。一个没有测试和使用说明的代码仓库，不能算成熟的 DSSA 资产库。

六、应用实例化活动

当具体项目使用 DSSA 时，需要开展应用工程活动。首先将项目需求映射到领域参考需求，区分已覆盖能力、需要配置的能力、需要扩展的能力和完全不在领域范围内的能力。然后选择可变点和构件，完成配置、组装、适配和定制开发。最后对实例化后的系统进行完整验证。

应用实例化的关键是保持领域资产与项目代码的边界。项目可以通过扩展点表达特殊需求，不应为了短期交付直接修改公共核心；如果确实需要修改，应评估对其他应用的影响，形成版本分支、兼容策略和迁移计划。

七、共性分析与可变性分析方法

可以使用特征模型表达 DSSA 的共性和可变性。特征分为必选、可选、互斥和依赖四类：所有应用都必须具备的功能是必选特征；部分应用需要的是可选特征；只能选择一个方案的是互斥特征；选择某项后必须同时选择另一项的是依赖特征。

例如支付领域：交易受理是必选，银行卡支付、钱包支付和对公转账是可选或互斥组合；启用分账功能可能依赖对账能力；启用高风险交易时必须依赖增强审计和人工复核。把这些关系写清楚，应用实例化时就能自动检查组合是否有效。

八、质量属性在 DSSA 活动中的位置

质量属性不能等到领域实现后才补充。领域分析阶段要收集多个应用共同的性能、可用性、安全性、可维护性和互操作性目标；领域设计阶段要把目标转成架构策略；领域实现阶段要提供可复用机制；应用实例化阶段要根据具体规模重新验证。

例如领域共同要求关键操作可审计，参考架构就应统一审计事件模型；如果不同应用的数据敏感等级不同，领域架构应提供分级加密和访问控制扩展点，而不是假设所有应用采用同一安全策略。

九、案例分析：医院预约挂号 DSSA

某公司需要为多家医院建设预约挂号系统。领域分析发现，共性包括科室、医生、号源、患者、预约、取消、支付、通知和审计；可变点包括医院科室层级、号源生成规则、实名校验方式、支付渠道、爽约处理规则和接诊排班方式。

领域设计形成参考架构：患者与身份子系统负责认证；号源中心负责资源发布和锁定；预约服务负责状态流转；规则引擎承载医院差异；支付适配器连接不同渠道；通知构件支持短信、公众号和应用推送；审计服务记录关键操作。数据上，号源锁定采用短事务和超时释放，预约状态通过事件通知其他服务，避免多个应用直接修改号源表。

领域实现提供号源、预约、支付和通知的核心构件、标准接口、测试模板和部署脚本。具体医院接入时，通过配置科室树、排班规则和支付渠道完成实例化；对于特殊的分时预约和黑名单规则，通过策略扩展实现。验证阶段重点测试高峰抢号、重复提交、支付超时、取消回滚、通知失败和医院系统断连。

十、基本活动之间的关系

领域分析决定“复用什么”，领域设计决定“如何组织和变化”，领域实现决定“怎样提供可用资产”，应用实例化决定“怎样服务具体项目”。如果领域分析不充分，设计会抽象错误；如果领域设计缺少可变点，实现会变成僵化平台；如果领域实现缺少测试和文档，应用无法安全复用；如果应用实例化反复修改核心，DSSA 会快速分叉。

十一、练习题

题1

DSSA 的领域分析、领域设计和领域实现分别解决什么问题？

参考答案

领域分析识别领域边界、概念、共性、可变性和约束；领域设计形成参考架构、领域模型、构件、接口和可变点方案；领域实现把设计转化为框架、可复用构件、测试、文档和部署资产。三者依次回答“复用什么、如何组织、怎样落地”。

题2

为什么不能把所有变化都实现为配置项？

参考答案

复杂规则和结构变化用配置表达会导致配置爆炸、难以理解和难以测试。应根据变化性质选择策略、规则引擎、插件、适配器或流程模板，并提供版本、校验、灰度和回滚机制。

题3

应用工程发现某项目的特殊需求在三个项目中反复出现，应如何处理？

参考答案

应将该需求反馈给领域工程，重新评估是否属于领域共性或稳定可变点；如果成立，就更新领域模型、参考架构和资产库，提供标准扩展点或可复用构件，而不是继续在各项目中重复定制。

十二、论文写作素材

论文中可按“领域分析—领域设计—领域实现—应用实例化—验证反馈”组织一段完整实践。重点写清多个应用的共性如何被识别，变化点通过何种机制承载，公共构件如何保持边界，以及通过哪些质量属性测试证明 DSSA 有效。避免只写“采用了 DSSA”，而要写出活动、产物和结果。

十三、今日复盘

本节核心口诀是：分析找共性，设计定结构，实现做资产，实例化选变体，验证促演进。遇到案例题，先划领域边界，再列共性与可变性，最后把每个变化映射到配置、策略、插件、适配器或构件组合。