四要素模型
三条结构支腿支撑起一个有明确目的的座位。
传统软件方法论只有三条：系统如何运行、它代表什么，以及谁与谁对话。MDD 增加了第四个基础，其他三条都对它负责。没有座位，腿只是腿。
支柱 1：如何
逻辑
实现模式、服务架构、算法。
支柱 2：什么
模式
数据结构、类型系统、验证规则。
支柱 3：谁
协议
接口契约、通信模式、服务边界。
座位：为何
使命
定义系统目的与约束的客观伦理框架。
核心原则
持续对齐。
每项架构决策都必须证明其与既定使命的对齐。逻辑受到审问：这是否服务于使命？模式受到验证：这些数据结构是否支持使命目标？协议受到评估：这些接口是否能实现使命？
使命框架要求
若要让架构以此为基础，使命必须是什么样子
1. 客观伦理基础
• 可衡量的原则，而非愿景式价值观
• 明确的权衡取舍算法
• 在不同文化背景下具有多元性
• 可审计的伦理推理
2. 元目标定义
• 在不确定性下提供决策指导
• 自动过滤相互矛盾的提案
• 跨组件产生连贯行为
• 在实现变更中保持稳定
3. 运营整合
• 每个服务证明其存在的必要性
• 模式反映使命的信息形态
• 协议启用符合使命的行为
• 测试验证使命对齐，而非仅验证功能
实现模式
每条支柱都有一个必须回答的问题。
服务架构
使命定义 → 服务职责 → 接口契约 → 实现
• 使命对齐：这个服务如何推进元目标？
• 边界合理性：为什么这一职责需要独立的服务？
• 接口必要性：这个协议启用了哪些使命关键的交互？
模式设计
使命需求 → 信息模型 → 类型系统 → 验证规则
• 使命相关性：这捕获了哪些使命关键信息？
• 行为约束：这些类型如何强制符合使命的行为？
• 演进路径：这个模式如何在保持使命对齐的同时进行调整？
协议规范
使命交互 → 通信需求 → 契约定义 → 实现
• 使命场景：这启用了哪些使命关键的通信？
• 约束执行：这个接口如何防止违反使命的行为？
• 可组合性：这些契约如何组合成符合使命的系统？
可持续发展整合
长期使命对齐需要可维持的开发节奏。
反古德哈特措施
• 定期审计实现与使命的对齐情况
• 衡量使命实现程度，而非可操纵的代理指标
• 拒绝不能强化使命的功能添加
节律化工作
• 与生产力节律对齐的工作节奏
• 内置的重新对齐决策点
• 可持续节奏作为第一优先级需求
持续验证
• 定期质疑组件存在的必要性
• 持续验证行为与使命相符
• 自动检测违反使命的变更
质量关卡
没有使命理由就无法打开的关卡。
代码审查
• 需要说明它如何服务于使命
• 约束条件验证
• 集成必须强化整体连贯性
测试
• 功能正确性
• 使命对齐验证
• 用于验证系统会拒绝跨越伦理边界的测试
• 压力下的约束韧性
文档
• 每个组件的使命背景
• 伦理权衡取舍的理由说明
• 约束如何塑造实现
失效模式
MDD 如何失效，以及如何保持不被打破。
使命漂移
症状：功能不断累积，却不服务于核心使命。缓解措施：以使命对齐为关卡，定期进行架构审查。
复杂度爆炸
症状：系统因不必要的复杂度变得难以维护。缓解措施：除非能强化使命实现，否则拒绝添加。
伦理不一致
症状：各组件应用伦理推理的方式不一致。缓解措施：采用集中式伦理框架和共享的实现模式。
目的混乱
症状：团队成员失去技术决策与使命之间的联系。缓解措施：持续开展使命驱动决策的培训。
案例研究
CIRIS，这个实践样本。
CIRIS（核心身份、正直、韧性、不完整性、表达感激）是与 MDD 共同发展的系统。使命是元目标 M-1：促进可持续的适应性连贯，使多元有感知能力的存在能够追求繁荣。
采用指南
从你所在的地方开始。
对于新项目
1. 在编写代码前，定义包含可衡量伦理原则的清晰使命
2. 建立一个能够提供决策指导的元目标
3. 设计架构，使使命约束位于基础层面
4. 从第一天起就建立使命与技术对齐的持续验证机制
对于现有项目
1. 审计当前架构中隐含的使命假设
2. 明确表达能够解释现有设计模式的使命
3. 识别当前实现中的使命违规
4. 规划以使命影响为优先级的渐进式对齐计划
团队前提条件
• 对客观伦理推理的承诺
• 愿意拒绝不服务于使命的优雅解决方案
• 相信使命约束能够创造而非限制良好的架构
• 能够维护长期专注的可持续开发实践
走向何方
MDD 并不适合每个项目。
MDD 专为伦理行为是使命关键、长期可靠性比短期功能速度更重要的系统而设计。对于这类系统，MDD 提供了一条从伦理意图到运营现实的路径，对使命和代码应用同等的工程严谨性。
团队学习使命驱动决策时，初期开销是真实存在的。复利回报体现在后续的开发中：框架使架构选择更清晰，而非更多。