Day29-04｜7.5.4 DSSA 的建立过程：从领域范围到可复用资产

一、教材定位

DSSA 的建立过程是第7章软件架构复用内容的收束。前面学习了 DSSA 的定义、基本活动和参与人员，本节将它们组织成一套可执行的方法。DSSA 建设不是单个项目的临时设计，而是围绕一个领域持续开展的工程：选择领域，分析应用，提炼共性，识别变化，设计参考架构，开发领域构件，验证并发布资产，再由应用项目使用和反馈。

二、建立过程总览

建立 DSSA 可以概括为以下步骤：确定领域和目标，收集领域资料，分析已有应用，提炼参考需求，识别共性与可变性，设计领域模型和参考架构，确定可复用构件与扩展点，实现领域资产，选择试点应用验证，建立资产库和治理机制，持续维护和演进。

这些步骤并非严格一次性串行。领域边界可能因分析结果调整，试点应用可能暴露新的变化点，运行反馈可能促使参考架构升级。因此实际过程通常是迭代的，但必须保留每次迭代的决策、假设和验证证据。

三、第一阶段：确定领域范围

领域范围应同时从业务、产品、组织和技术角度确定。业务角度关注哪些流程和能力属于同一问题域；产品角度关注哪些系统具有共同市场或客户；组织角度关注哪些团队可以共同治理资产；技术角度关注哪些系统存在相似部署、数据和集成约束。

领域选择可以使用四项判断：应用数量是否足够，应用之间是否存在稳定共性，业务差异是否可以通过可变点表达，复用收益是否能够覆盖领域工程成本。如果只有一个系统且未来没有相近应用，建立完整 DSSA 可能不划算。

四、第二阶段：收集领域资料

资料来源包括需求规格、业务制度、接口协议、数据库模型、现有代码、运行日志、故障报告、用户反馈、测试用例、部署脚本、监管标准和领域专家访谈。不能只研究成功案例，还要收集异常流程和历史故障，因为架构的复用价值往往体现在边界条件和恢复机制上。

收集资料后要建立术语表和资料可信度。不同项目对同一概念的称呼、含义和数据范围可能不同，必须由领域专家确认。对于旧系统中仅因历史原因存在的实现细节，不应直接当作领域共性。

五、第三阶段：分析已有应用

对已有应用进行横向比较，识别功能、数据、流程、接口、质量属性和部署方式的相同点与不同点。可以采用应用矩阵：行表示应用，列表示领域能力，单元格标注必选、可选、特殊实现或不适用。通过矩阵可以发现哪些能力适合进入核心资产，哪些能力应设计为变体，哪些能力不应纳入 DSSA。

还要分析现有应用的问题：重复代码、接口不一致、跨系统共享数据库、监控缺失、部署复杂、性能瓶颈和安全缺陷。这些问题能够帮助架构师确定 DSSA 不仅要复用功能，还要改善整体质量属性。

六、第四阶段：提炼参考需求

参考需求由多个应用的共性需求组成，包含功能需求和质量属性需求。功能方面可能包括客户、订单、流程、查询、通知和审计；质量方面可能包括吞吐量、响应时间、可用性、恢复时间、数据隔离、可追踪性和可维护性。

参考需求不能简单取各项目需求的并集，否则会形成过大的平台。应区分稳定共性、可选能力、项目特例和未来设想，并为每项需求注明来源、适用范围、优先级、验证方式和可变性。

七、第五阶段：识别共性和可变性

共性分析回答“所有或大多数应用都需要什么”；可变性分析回答“哪些地方会不同，为什么不同，以及如何支持不同”。变化可以发生在数据字段、业务规则、流程、接口协议、部署环境、权限模型和质量目标上。

可变点描述至少包括名称、变化范围、默认实现、可选实现、决定者、决定时间、承载机制和验证方式。例如“支付渠道”可由项目配置选择，但“支付状态机”属于核心规则；“设备协议”由适配器承载，而“生产订单生命周期”属于领域核心。

八、第六阶段：设计领域模型和参考架构

领域模型描述实体、值对象、聚合、领域服务、事件和规则。参考架构将这些概念映射到系统子域、服务、构件、数据存储、消息通道和部署节点。架构设计应明确哪些数据由哪个构件拥有，哪些事件可以对外发布，哪些接口是稳定契约。

参考架构还要体现质量属性策略。例如高可用要求对应多实例、健康检查和故障切换；高性能要求对应缓存、异步、分片或读写分离；安全要求对应身份认证、最小权限、加密和审计；可维护性要求对应模块边界、自动化测试、日志和配置治理。

九、第七阶段：实现和组织领域资产

资产包括核心构件、可选构件、适配器、插件、框架、接口规范、数据模型、测试模板、配置模板、部署脚本和文档。每个资产要登记版本、负责人、依赖、适用范围、已知限制和验证结果。

资产库不能只是文件目录。应支持检索、版本、权限、审批、使用统计、缺陷跟踪和生命周期管理。对于公共服务，要提供示例工程和快速开始文档；对于架构模式，要提供适用场景、反例和质量属性说明；对于部署模板，要提供环境变量和回滚方法。

十、 第八阶段：试点验证

DSSA 不应直接在所有项目中推广，应选择具有代表性且风险可控的试点应用。试点要覆盖核心共性、主要可变点和关键质量属性。验证内容包括功能覆盖、构件组合、性能容量、安全隔离、故障恢复、部署发布和团队使用成本。

试点成功的标准不只是“系统上线”，还要看复用比例、定制工作量、缺陷数量、交付周期、运行指标和资产反馈。若试点发现公共构件过度抽象或可变点设计不合理，应回到领域设计阶段修正，而不是强行推广。

十一、第九阶段：推广、治理与演进

推广阶段要建立版本兼容、变更评审、质量门禁、支持窗口和退出机制。领域资产升级应说明影响范围、迁移步骤和回滚方案；项目使用资产时应登记版本和配置；重大差异应记录为架构例外。

运行中的问题要反馈给领域工程：重复适配说明资产缺少扩展点，重复故障说明公共质量机制不足，多个项目提出同类需求说明新的领域共性正在形成。DSSA 不是完成一次后永久不变，而是随着领域和产品线演进不断重构。

十二、案例分析：保险理赔 DSSA

某公司为车险、财产险和健康险建设理赔系统。第一阶段确定领域范围为“保险理赔受理、审核、赔付和追踪”，而不是整个保险业务。资料分析发现，共性包括报案、材料收集、案件分派、规则审核、人工复核、赔付、通知和审计；可变点包括险种规则、材料清单、赔付计算、外部查勘接口和反欺诈策略。

领域架构师设计理赔参考架构：案件中心维护案件生命周期，材料中心管理证据，规则服务执行险种规则，工作流负责审核流转，支付服务负责赔付，反欺诈服务作为可选构件，外部系统通过适配器接入。数据上，案件服务拥有案件状态，规则服务不直接修改案件库，而通过决策结果和事件协作。

车险项目作为试点，重点验证高峰报案、图片上传、规则计算、人工转派和支付失败恢复。试点发现健康险需要更复杂的医疗材料和人工审核，于是将材料规则和审核策略设计为扩展点，而没有修改案件核心。最终 DSSA 支持多个险种，同时保持核心生命周期稳定。

十三、建立过程中的常见问题

第一，领域选择过宽，导致共性不足、平台复杂。第二，只分析成功项目，不分析异常和运维问题。第三，把所有项目需求都塞进参考需求，造成大而全。第四，没有明确可变点的决定者和承载方式。第五，缺少试点和质量验证就推广。第六，资产入库后没有负责人、版本和退出机制。第七，应用团队反复修改核心构件，形成分支和版本碎片化。

十四、练习题

题1

建立 DSSA 为什么要选择试点应用？

参考答案

试点可以在可控范围内验证领域边界、共性分析、可变点、构件组合和质量属性策略，尽早暴露过度抽象、性能不足、接口不适用和团队使用成本问题。试点结果可用于修正 DSSA，降低全面推广风险。

题2

如何判断某项能力应进入 DSSA 核心资产？

参考答案

应综合考虑多个应用是否稳定需要、业务语义是否一致、未来变化是否可控、复用收益是否覆盖建设维护成本、质量是否有验证证据以及是否存在明确责任人。仅因为某项目代码重复，不能直接认定为领域核心。

题3

应用项目中反复出现同类适配代码，说明什么？

参考答案

说明 DSSA 的扩展点、接口契约或适配资产可能不足，也可能说明新的领域共性正在形成。应收集多个项目证据，分析是否值得抽象为标准适配器、策略或构件，并通过试点验证后纳入资产库。

十五、论文写作素材

论文中可以按“领域选择、资料分析、共性与可变性、参考架构、资产实现、试点验证、推广治理”展开。每个阶段写清输入、决策、产物和结果，例如“通过应用矩阵识别三类共性能力，通过特征模型表达可选支付渠道，使用试点系统验证高并发和故障恢复，最终将重复适配逻辑沉淀为标准构件”。

十六、今日复盘

DSSA 建立过程可以记为：定领域、收资料、比应用、提需求、找共性、建架构、做资产、试点验、推广管、持续演进。案例题中只要按这条链展开，并补充质量属性和治理机制，就能形成完整的高级架构答案。