Day28-48｜7.4.3 软件架构复用的对象及形式

一、复用对象的全景

软件架构复用的对象可以从抽象到具体排列为：原则、需求知识、分析模型、设计决策、架构风格、参考架构、框架与中间件、构件、接口契约、数据模型、测试资产、部署资产和运维知识。不同对象的稳定性、复用成本和风险不同，不能用同一种方式管理。

二、架构知识的复用

知识复用是最容易被忽略、却最有长期价值的形式。架构决策记录应包含背景、问题、候选方案、决策、后果和验证证据。复用时不是只看结论，而要判断当时的约束是否仍然成立。例如“采用消息队列”背后的原因可能是削峰，也可能是跨系统解耦，两种背景对应的容量、可靠性和一致性设计并不相同。

分析模型复用包括角色模型、领域概念、质量属性场景、数据流和故障模型。它们可以作为新项目的起点，但必须接受新领域专家的确认，防止把旧领域概念误认为通用概念。

三、结构与模式的复用

架构风格和模式可以作为结构模板。层次式架构复用职责分层，事件驱动复用生产者、事件总线、消费者和重试机制，微内核复用核心系统与插件隔离关系。模式复用的重点是理解“问题—上下文—方案—权衡”，而不是只背模式名称。

参考架构比单个模式更完整，通常包含逻辑视图、开发视图、部署视图、数据视图、质量属性策略、接口规范和治理要求。复用参考架构时应先裁剪，再补充领域差异，最后形成项目架构基线。

四、构件与服务的复用

构件复用可分为黑盒复用、白盒复用和灰盒复用。黑盒复用只依赖公开接口和行为契约，内部实现不可见，耦合较低；白盒复用允许修改内部实现，灵活但维护成本高；灰盒复用了解部分内部机制，通过配置和扩展点适配。服务复用必须明确数据所有权、调用协议、幂等性、超时、重试、限流和版本兼容。

一个服务即使功能相似，也可能不适合复用。例如“用户服务”在后台管理系统中关注组织和权限，在交易系统中还涉及实名、风控和隐私等级。复用前要比较领域语义，而不是比较服务名称。

五、数据与接口的复用

数据模型复用有三种常见形式：直接共享数据库、通过数据服务访问、通过领域事件共享事实。直接共享见效快但耦合高，表结构变化会影响多个系统；数据服务保护了数据库边界，但增加调用链；事件共享降低了实时耦合，却要求处理最终一致性、重复事件和顺序问题。高级案例答题应说明为何选择某种形式及其补偿机制。

接口复用要关注语义契约、错误码、鉴权、幂等键、分页、版本和兼容策略。仅复制URL和字段清单不能构成可复用接口资产。

六、过程与运维资产的复用

持续集成流水线、质量门禁、发布策略、监控指标、告警规则、备份脚本和灾备演练方案也属于架构复用对象。它们能够把架构要求落实到工程过程。例如“高可用”只有落实为多实例、健康检查、自动切换、告警和演练，才是真正可复用的架构资产。

七、复用形式的选择

常见形式包括复制、参数化、配置化、继承、组合、包装适配和平台化。复制适合稳定且简单的模板；参数化适合少量变化；配置化适合规则差异；组合适合多个独立能力；包装适配适合接口不一致；平台化适合多个项目共享并持续演进的能力。形式选择取决于变化频率、隔离要求、性能、团队能力和治理成本。

八、案例分析

某政务平台需要建设多个委办局应用。团队复用了统一认证、电子印章、消息通知、日志审计和文件存储，但没有共享各委办局的业务数据库。认证采用标准协议，消息通过统一事件格式接入，文件服务通过租户隔离保证数据边界，审计平台按系统标识区分来源。这个案例体现了“横向能力复用、业务数据隔离、接口契约统一”的组合形式。

九、练习题

题1

共享数据库和共享数据服务各有什么架构后果？

答案

共享数据库调用简单、性能直接，但形成强耦合，表结构和事务边界难以独立演进；共享数据服务保护存储边界，便于权限和治理，但引入网络延迟、可用性依赖和接口版本管理。应结合一致性、性能和自治性选择。

题2

为什么架构决策记录比代码更适合跨项目复用？

答案

代码只能展示一种实现，决策记录说明问题背景、候选方案和权衡后果，能够帮助新项目判断结论是否适用，避免脱离上下文盲目复制。

十、复盘

看到“复用对象及形式”，按“知识—结构—构件—数据—过程”列对象，再按“复制、适配、配置、组合、平台化”说明形式。案例中必须写边界、契约和验证。

十一、对象之间的组合关系

真实项目很少只复用一种对象。一个可复用平台通常同时包含参考架构、接口契约、数据规范、服务构件、部署模板和测试用例。若只复用服务而不复用契约，接入方会产生大量私有约定；只复用代码而不复用监控和发布资产，运行质量无法继承；只复用数据表而不复用数据所有权规则，则会造成跨系统直接写库。因此复用对象应作为一个资产包管理，明确核心对象、可选对象和禁止修改的对象。

例如统一消息资产包可以包含：事件命名规范、消息结构、生产者SDK、消费者模板、重试策略、死信处理、幂等样例、监控指标和压测报告。项目可以组合使用其中部分内容，但必须保留事件版本、追踪ID和可靠投递等核心契约。

十二、选择形式的判断题

若资产变化频率低、调用方多，适合平台化；若资产只存在少量参数差异，适合参数化；若不同项目有明显协议差异，适合包装适配；若资产内部实现需要随项目变化，适合白盒或源码复用；若数据所有权必须隔离，应优先服务或事件复用，避免共享数据库。答题时把“形式”与“约束”绑定，而不是罗列名词。

十三、综合案例

真实项目很少只复用一种对象。一个可复用平台通常同时包含参考架构、接口契约、数据规范、服务构件、部署模板和测试用例。若只复用代码而不复用监控和发布资产，运行质量无法继承；只复用数据表而不复用数据所有权规则，则会造成跨系统直接写库。建议为资产标注“必须复用、建议复用、可选复用、禁止直接复用”。

黑盒复用强调通过公开契约使用资产，便于升级和替换；白盒复用便于修改内部实现，却容易形成分叉；灰盒复用在灵活性与治理之间折中。若资产承担关键业务能力，应优先选择黑盒或灰盒，并提供扩展点、版本策略和兼容测试，不要让项目直接依赖内部类、内部表或未公开配置。

复用形式的选择最终要服务于自治性、可演进性和质量属性，而不是追求表面统一。

所以，复用对象必须与复用形式、适用上下文和验证证据一起记录，才能成为真正可传承的架构资产。 缺少其中任何一项，复用都可能退化为不可控的复制。 这也是区分架构复用与普通代码复用的关键。 对象越靠近架构决策，越需要记录适用条件和质量证据。 这也是资产治理的基础。 当对象存在数据或安全边界时，优先复用契约和能力，谨慎复用内部实现。

某集团复用商品中心建设医药电商。商品编码、库存、供应商和有效期管理均有特殊要求。处理方式应是：复用商品主数据接口和事件格式；通过领域扩展增加批次、有效期和冷链属性；库存不直接共享旧表，而通过库存服务维护所有权；对接审计、监控和发布模板；对过期商品拦截、库存一致性和高峰查询进行专项测试。最终形成“接口和平台能力复用，领域模型扩展，数据边界隔离”的方案。