Day29-03｜7.5.3 参与 DSSA 的人员：让领域知识、架构决策与复用工程形成合力

一、教材定位

DSSA 不是架构师一个人的工作。它同时涉及业务领域知识、软件架构设计、产品线规划、构件开发、测试验证、项目交付和资产治理。参与人员的职责边界如果不清晰，最容易出现两种问题：一是平台团队按照自己的技术偏好抽象出脱离业务的“通用平台”；二是业务项目为了短期交付不断修改公共核心，最终使 DSSA 失去稳定性和复用价值。

二、参与角色总览

三、领域专家

领域专家是 DSSA 的知识来源，通常来自业务部门、行业顾问、客户代表、运营人员或长期维护旧系统的人员。他们负责解释领域术语、业务目标、流程规则、例外情况和实际约束。例如在银行领域，架构师可能知道账户、交易和消息如何建模，但只有业务专家能够解释日终清算、冲正、挂账、差错处理和监管报送的真实语义。

领域专家不一定直接设计软件结构，但必须参与共性和可变性确认。某个能力是否是领域共性，不能只看代码重复，还要看业务意义是否稳定。领域专家还要参与验收，确认 DSSA 没有把不同业务概念错误合并。

四、领域架构师

领域架构师是 DSSA 的主要技术负责人，负责把领域知识转化为架构资产。他需要界定领域边界，组织共性分析和可变性分析，建立领域模型，设计参考架构，确定质量属性策略，划分核心与扩展部分，并维护架构决策记录。

领域架构师不能只关注逻辑分层，还要处理数据所有权、接口版本、部署拓扑、故障传播、权限边界、构件替换和演进路线。面对业务专家的需求，领域架构师要判断它是稳定共性、可配置变化、插件扩展，还是不应纳入 DSSA 的项目特例。

五、应用架构师

应用架构师负责把 DSSA 应用到具体项目中。他需要理解领域资产的适用范围，选择合适的变体，设计项目级适配方案，补充项目特有能力，并保证项目架构不违反 DSSA 的核心约束。

应用架构师还承担反馈责任。如果某个适配逻辑在多个项目中重复出现，应将其反馈给领域架构师；如果公共构件不能满足项目质量目标，应提供性能、安全和可靠性证据，推动领域资产改进，而不是私下复制一份分支。

六、产品线经理与业务负责人

产品线经理关注 DSSA 是否值得建设以及如何产生长期收益。他需要分析产品线范围、应用数量、共性比例、市场节奏、建设成本和复用收益，安排领域工程与应用工程的投入比例。

业务负责人负责确定业务优先级、目标用户和商业价值。DSSA 并非越通用越好，如果产品线中的应用差异过大，强行建设统一平台会拖慢交付。产品线经理应推动阶段性建设：先从高价值、稳定且重复率高的能力开始，经过试点后再扩大范围。

七、构件开发人员与平台工程师

构件开发人员负责将领域设计落实为可运行资产，包括公共服务、领域框架、SDK、插件机制、配置中心、接口适配器、测试工具、部署模板和监控模板。开发人员需要遵守构件契约、版本兼容和扩展点设计，不能把项目特定逻辑隐藏在公共构件中。

平台工程师关注构件的工程化交付：自动构建、依赖管理、制品仓库、环境配置、持续集成、持续交付、灰度发布、日志采集和运行监控。没有工程化支撑，DSSA 资产很难被多个项目稳定使用。

八、项目经理

项目经理协调领域工程和应用工程的资源与节奏。他需要识别复用依赖、安排资产验证、控制公共构件变更的影响，并在项目计划中留出适配、联调、性能测试和迁移演练的时间。

项目经理还要防止“为了按期上线而直接修改核心资产”。如果项目必须采取临时方案，应建立技术债务和回收计划，明确后续是否反哺 DSSA、是否保留适配层、何时消除分支。

九、测试、质量、安全和运维人员

测试人员要验证 DSSA 资产在多个应用和多个变体中的可复用性，重点关注构件组合、边界条件、版本兼容、异常恢复和回归影响。质量人员负责建立质量门禁，确保资产具有文档、测试报告、缺陷记录和支持范围。

安全人员负责身份认证、授权、数据分级、加密、审计、漏洞和合规评估。运维人员负责容量、监控、告警、备份、恢复、发布和故障演练。DSSA 若只描述业务功能而没有这些角色参与，就很难把可用性、安全性和可维护性真正落实。

十、角色协作机制

参与人员不能只靠临时会议协作，应建立正式机制：领域术语评审统一语言；架构评审确认边界与质量属性；构件评审确认接口、版本和扩展点；安全评审确认风险；发布评审确认部署和回滚；运行复盘将真实问题反馈到资产库。

可以建立责任矩阵：领域专家负责业务语义，领域架构师负责 DSSA 决策，应用架构师负责项目实例化，构件团队负责实现和维护，测试团队负责证据，项目经理负责协调和交付。对于每个关键决策必须有唯一责任人，同时允许相关角色提出意见。

十一、案例分析：制造执行系统 DSSA

某企业为多个工厂建设制造执行系统。领域专家提供工艺、工单、设备、物料和质量检验知识；领域架构师提炼生产计划、工单执行、设备采集和质量追溯的共性，设计领域事件和构件边界；产品线经理确认哪些能力优先平台化；应用架构师根据不同工厂选择设备协议和排产规则；构件团队开发设备适配器、工单服务和追溯组件；安全人员设计操作审计和设备身份；运维人员建立边缘节点监控和断网恢复；测试团队验证高峰生产、设备离线、重复采集和质量追溯。

最终，稳定共性进入 DSSA，设备厂商差异通过适配器表达，工厂排产差异通过规则策略表达。该案例说明参与人员的价值不是简单分工，而是共同把业务差异转换成可治理的架构变化点。

十二、练习题

题1

领域专家和领域架构师的职责有什么区别？

参考答案

领域专家提供业务概念、规则、流程、例外和实际约束，确认架构是否符合业务语义；领域架构师负责把这些知识转化为领域模型、共性与可变性、参考架构、构件、接口和质量属性策略。前者回答业务是什么，后者回答如何形成可复用的软件体系结构。

题2

应用架构师发现公共构件无法满足项目性能目标，应如何处理？

参考答案

先通过压测和容量分析确认问题，再判断是配置不当、适配层瓶颈还是构件本身设计缺陷；将证据反馈给领域架构师和构件团队，评估升级、扩展、替换或项目隔离方案。不能直接复制公共构件并长期形成无人维护的分支。

题3

为什么安全和运维人员必须参与 DSSA？

参考答案

因为 DSSA 的复用不仅涉及功能，还涉及身份、授权、数据保护、监控、部署、备份、恢复和故障演练。缺少安全和运维参与，架构资产可能在开发环境可用，却无法满足生产环境的可靠性和合规要求。

十三、论文写作素材

论文可以写“我组织领域专家、领域架构师、应用架构师、开发、测试、安全和运维共同参与 DSSA 建设。领域专家负责确认业务语义，领域架构师负责共性和可变性分析，应用架构师负责具体实例化，构件团队负责资产实现，测试、安全和运维团队负责质量证据。通过责任矩阵和架构评审保证决策闭环，最终避免公共平台脱离业务或被项目随意修改。”

十四、今日复盘

参与 DSSA 的人员可以按“懂业务、定架构、做资产、落项目、保质量、管运行”记忆。考试答题不要只罗列角色名称，要写每个角色的职责、输入、产物和协作关系。