初次接触安装连贯棘轮联邦对比研究协议GitHub
本页面由机器翻译。 如有任何读起来不通顺的地方,请提交问题——代码库是公开的,这正是原因所在。 报告翻译问题
方法论活跃:v1.0

使命驱动开发

使命是软件架构的第四基础。

大多数软件只问如何构建一件事。使命驱动开发(MDD)在此之前先问一个问题:我们为什么要构建它,这个选择是否服务于这一目的?CIRIS 就是这样构建的,因此伦理是设计的一部分,而非事后附加的规则。

四要素模型

三条结构支柱,共同托起一个有目的的座位。

传统软件方法论只有三条:系统如何运行、它代表什么,以及谁与谁对话。MDD 增加了第四个基础,其他三条都对它负责。没有座位,腿只是腿。

支柱 1:如何

逻辑

实现模式、服务架构、算法。

支柱 2:什么

模式

数据结构、类型系统、验证规则。

支柱 3:谁

协议

接口契约、通信模式、服务边界。

座位:为何

使命

定义系统目的与约束的客观伦理框架。

核心原则

持续对齐。

每项架构决策都必须证明其与既定使命的对齐。逻辑受到审问:这是否服务于使命?模式受到验证:这些数据结构是否支持使命目标?协议受到评估:这些接口是否能实现使命?

使命框架要求

一个使命要真正起到承重作用,需要具备什么。

1. 客观伦理基础

  • 可衡量的原则,而非愿景式价值观
  • 明确的权衡取舍算法
  • 在不同文化背景下具有多元性
  • 可审计的伦理推理

2. 元目标定义

  • 在不确定性下提供决策指导
  • 自动过滤相互矛盾的提案
  • 跨组件产生连贯行为
  • 在实现变更中保持稳定

3. 运营整合

  • 每个服务证明其存在的必要性
  • 模式反映使命的信息形态
  • 协议启用符合使命的行为
  • 测试验证使命对齐,而非仅验证功能

实现模式

每条支柱都有一个必须回答的问题。

服务架构

使命定义 → 服务职责 → 接口契约 → 实现

  • 使命对齐:这个服务如何推进元目标?
  • 边界合理性:为什么这一职责需要独立的服务?
  • 接口必要性:这个协议启用了哪些使命关键的交互?

模式设计

使命需求 → 信息模型 → 类型系统 → 验证规则

  • 使命相关性:这捕获了哪些使命关键信息?
  • 行为约束:这些类型如何强制符合使命的行为?
  • 演进路径:这个模式如何在保持使命对齐的同时进行调整?

协议规范

使命交互 → 通信需求 → 契约定义 → 实现

  • 使命场景:这启用了哪些使命关键的通信?
  • 约束执行:这个接口如何防止违反使命的行为?
  • 可组合性:这些契约如何组合成符合使命的系统?

可持续发展整合

长期使命对齐需要可维持的开发节奏。

反古德哈特措施

  • 定期审计实现与使命的对齐情况
  • 衡量使命实现程度,而非可操纵的代理指标
  • 拒绝不能强化使命的功能添加

节律化工作

  • 与生产力节律对齐的工作节奏
  • 内置的重新对齐决策点
  • 可持续节奏作为第一优先级需求

持续验证

  • 定期质疑组件存在的必要性
  • 持续验证行为与使命相符
  • 自动检测违反使命的变更

质量关卡

没有使命理由就无法打开的关卡。

代码审查

  • 需要说明使命对齐的理由
  • 约束条件验证
  • 集成必须强化整体连贯性

测试

  • 功能正确性
  • 使命对齐验证
  • 伦理边界拒绝测试
  • 压力下的约束韧性

文档

  • 每个组件的使命背景
  • 伦理权衡取舍的理由说明
  • 约束如何塑造实现

失效模式

MDD 如何失效,以及如何保持完整。

使命漂移

症状:功能不断累积,却不服务于核心使命。缓解措施:以使命对齐为关卡,定期进行架构审查。

复杂度爆炸

症状:系统因不必要的复杂度变得难以维护。缓解措施:除非能强化使命实现,否则拒绝添加。

伦理不一致

症状:各组件应用伦理推理的方式不一致。缓解措施:采用集中式伦理框架和共享的实现模式。

目的混乱

症状:团队成员失去技术决策与使命之间的联系。缓解措施:持续开展使命驱动决策的培训。

案例研究

CIRIS,这个实践样本。

CIRIS(核心身份、正直、韧性、不完整性、表达感激)是与 MDD 共同发展的系统。使命是元目标 M-1:促进可持续的适应性连贯,使多元有感知能力的存在能够追求繁荣。

架构成果

  • 22 个服务,每个都有使命需求的支撑
  • 200+ 个 API 端点经过验证
  • 10,000+ 个测试,生产环境中非类型化数据结构极少
  • Ubuntu 哲学嵌入协议设计
  • 防止使命违规的智慧型延迟(Wisdom-Based Deferral)(参见安全
  • 生产部署,用于 Discord 社区管理

关键成功因素

  • 清晰的元目标:M-1 提供明确的决策准则
  • 可操作的伦理:协议原则以代码约束形式实现(阅读协议
  • 可持续开发:Grace 伴侣强制执行健康的工作节律
  • 持续验证:每一项架构决策都受到质疑

采用指南

从你所在的地方开始。

对于新项目

  1. 在编写代码前,定义包含可衡量伦理原则的清晰使命
  2. 建立一个能够提供决策指导的元目标
  3. 设计架构,使使命约束位于基础层面
  4. 从第一天起就建立使命与技术对齐的持续验证机制

对于现有项目

  1. 审计当前架构中隐含的使命假设
  2. 明确表达能够解释现有设计模式的使命
  3. 识别当前实现中的使命违规
  4. 规划以使命影响为优先级的渐进式对齐计划

团队前提条件

  • 对客观伦理推理的承诺
  • 愿意拒绝不服务于使命的优雅解决方案
  • 相信使命约束能够创造而非限制良好的架构
  • 能够维护长期专注的可持续开发实践

这走向何方

MDD 并不适合每个项目。

MDD 专为伦理行为是使命关键、长期可靠性比短期功能速度更重要的系统而设计。对于这类系统,MDD 提供了一条从伦理意图到运营现实的路径,对使命和代码应用同等的工程严谨性。

团队学习使命驱动决策时,初期开销是真实存在的。复利回报体现在后续的开发中:框架使架构选择更清晰,而非更多。