基于本体驱动的完整软件建模方案和实施指南

人月聊IT

发布于 2026-03-26 19:51:39

190

大家好，我是人月聊IT。

今天继续分享一个本体驱动的建模规范和实施指南文件，供大家参考。注意该建模规范在我前面的本体建模文章的基础上进一步将本体模型的Markdown文件转化为YAML文件的描述进行描述。其次在原有的对象，行为，规则，场景模型的基础上，增加了主体模型和异常补偿模型。

注意该本体建模参考本体论建模思想对传统的面向对象分析建模和EDA事件驱动的建模进行融合。引入EDA建模思路核心原因是原有的基于流程驱动的建模往往容易导致业务行为活动的紧耦合并引入长周期事务处理。而引入EDA事件驱动后进一步对行为规则进行解耦，通过事件链来驱动完整业务流程的实现。同时实现我在前面文章提到过的，通过行为-》事件-》行为的完整链条更加容易实现后续本体需要的数据反向驱动业务的能力。

本体驱动的软件建模方案

Ontology-Driven Software Modeling Framework

完整建模规范 · 七大模型元文件 · 实施指南版本： 1.0 | 2026年3月作者：@人月聊IT

第一章方案概述与设计哲学

1.1 框架定位

本方案面向中小规模软件系统，以"本体"（Ontology）作为系统设计的核心隐喻，将业务世界中的"存在（What）"、"行为（How）"、"规则（Why）"、"场景（When/Flow）"分离建模，并通过事件驱动架构（EDA）实现运行时的松耦合。

与传统需求分析方法（如UML用例图、功能规格说明书）相比，本框架具有以下核心差异：

语义驱动：模型元素具有明确的业务语义，而非纯粹的技术描述
正交分解：对象、行为、规则、场景四个维度相互独立，可单独演进
事件解耦：通过事件链替代长事务，避免强耦合的同步调用链
可追溯性：每个实现单元都可以溯源到具体的本体模型定义

1.2 七大本体模型元文件总览

在初始四模型基础上，补充了权限主体模型、异常补偿模型和非功能性约束模型，形成完整的七模型体系：

编号	模型名称	核心职责
M1	对象模型 Object Model	定义数据实体、实体属性、实体间的双向关联与参照完整性约束
M2	行为模型 Behavior Model	定义对象的原子行为方法、触发条件、前置后置约束及产生的事件
M3	规则模型 Rule Model	定义可复用的解耦业务规则，包括计算规则、验证规则、推导规则
M4	场景模型 Scenario Model	定义业务流程与用例场景，通过对象行为和事件链组装完整业务流
M5	主体模型 Actor Model	定义系统参与者、角色、权限边界及行为执行授权关系
M6	异常补偿模型 Compensation Model	定义行为失败的异常分类、补偿策略及Saga协调机制
M7	质量约束模型 Quality Model	定义非功能性约束，包括性能SLA、可靠性要求、并发策略

1.3 模型间关系全景

七个模型之间的依赖与引用关系如下：

M4 场景模型      依赖   M2 行为模型  +  M6 异常补偿模型
M2 行为模型      依赖   M1 对象模型  +  M3 规则模型  +  M5 主体模型
M3 规则模型      引用   M1 对象模型（只读）
M5 主体模型      引用   M1 对象模型  +  M2 行为模型（权限绑定）
M6 异常补偿模型  引用   M2 行为模型（补偿行为）  +  M4 场景模型（Saga边界）
M7 质量约束模型  标注   M2 行为模型  +  M4 场景模型（QoS Annotation）

第二章 M1 对象模型

2.1 设计目标

对象模型是整个本体体系的基础，负责描述业务域中的核心数据实体及其关系，对应领域驱动设计（DDD）中的领域模型层。其范围包含三个核心关切：

实体定义：业务实体的属性、标识、生命周期状态
关联关系：实体之间的双向语义关系（聚合、组合、关联、依赖）
参照完整性：跨实体的完整性约束，内嵌于对象模型而非规则模型

2.2 模型元素规范

2.2.1 实体（Entity）

属性名	类型	说明
id	String / UUID	实体唯一标识，建议使用UUID v4
name	String	实体业务名称（中文，需唯一）
alias	String	英文标识符，用于代码映射
description	String	业务含义说明
lifecycle	Enum[]	实体生命周期状态列表，如 [草稿, 生效, 注销]
attributes	Attribute[]	属性集合，见下方属性规范
constraints	Constraint[]	参照完整性约束集合
tags	String[]	分类标签，如 [核心域, 支撑域]

2.2.2 属性（Attribute）

属性名	类型	说明
name	String	属性名（英文camelCase）
label	String	业务展示名（中文）
type	DataType	基础类型：String / Integer / Decimal / Date / DateTime / Boolean / Enum / Reference
required	Boolean	是否必填
unique	Boolean	是否唯一
defaultValue	Any	默认值
enumValues	String[]	当type=Enum时的枚举值列表
refEntity	EntityRef	当type=Reference时引用的实体
refCardinality	Enum	引用基数：ONE_TO_ONE / ONE_TO_MANY / MANY_TO_MANY

2.2.3 关联关系（Relation）

关联关系在对象模型中独立定义，支持双向语义描述（参考OWL的ObjectProperty）：

属性名	类型	说明
id	String	关系唯一标识
type	Enum	AGGREGATION（聚合）/ COMPOSITION（组合）/ ASSOCIATION（关联）/ DEPENDENCY（依赖）
sourceEntity	EntityRef	来源实体
targetEntity	EntityRef	目标实体
sourceRole	String	来源端角色名（如"所属订单"）
targetRole	String	目标端角色名（如"订单明细"）
sourceCardinality	Enum	来源端基数：ONE / ZERO_OR_ONE / MANY / ONE_OR_MORE
targetCardinality	Enum	目标端基数（同上）
inverseOf	RelationRef	反向关系引用（实现双向）
cascadeDelete	Boolean	是否级联删除

2.2.4 参照完整性约束（ReferentialConstraint）

属性名	类型	说明
constraintType	Enum	FOREIGN_KEY / UNIQUE_COMPOSITE / CHECK / NOT_NULL
scope	Enum	约束生效范围：ENTITY（实体内）/ RELATION（跨实体）
expression	String	约束表达式，使用受限的谓词逻辑语法
violationMessage	String	违反约束时的业务错误消息
enforcedAt	Enum	执行时机：PERSIST（持久化前）/ QUERY（查询时）

2.3 YAML 元文件模板

# M1 对象模型元文件 - object-model.yaml
model_type:OBJECT
version:"1.0"
domain:"订单管理"

entities:
-id:ORD-001
    name:订单
    alias:Order
    lifecycle:[草稿,待支付,已支付,已发货,已完成,已取消]
    attributes:
      -name:orderId
        label:订单号
        type:String
        required:true
        unique:true
      -name:status
        label:订单状态
        type:Enum
        enumValues:[草稿,待支付,已支付,已发货,已完成,已取消]
      -name:totalAmount
        label:订单总额
        type:Decimal
        required:true
    constraints:
      -constraintType:CHECK
        scope:ENTITY
        expression:"totalAmount >= 0"
        violationMessage:订单总额不能为负数

-id:ORD-002
    name:订单明细
    alias:OrderItem
    attributes:
      -name:itemId
        label:明细ID
        type:String
        required:true
        unique:true
      -name:productId
        label:商品ID
        type:Reference
        refEntity:PRD-001
        refCardinality:ONE_TO_MANY
      -name:quantity
        label:数量
        type:Integer
        required:true
      -name:unitPrice
        label:单价
        type:Decimal
        required:true
    constraints:
      -constraintType:CHECK
        scope:ENTITY
        expression:"quantity > 0 AND unitPrice >= 0"
        violationMessage:数量必须大于0，单价不能为负数

relations:
-id:REL-001
    type:COMPOSITION
    sourceEntity:ORD-001
    targetEntity:ORD-002
    sourceRole:所属订单
    targetRole:订单明细
    sourceCardinality:ONE
    targetCardinality:ONE_OR_MORE
    inverseOf:REL-001-INV
    cascadeDelete:true

第三章 M2 行为模型

3.1 设计目标

行为模型定义对象能够执行的原子行为方法。每个行为是单一对象发出的、不可再分的核心操作单元。复合行为（Composite Behavior）由多个原子行为通过场景模型编排，而非在行为模型内部内嵌。（本文件为@人月聊IT原创整理，转载注明出处）

关键设计原则：行为模型的核心约束是"原子性"——每个行为方法只做一件事，操作一个对象，产生确定性的状态变更。复杂的业务逻辑通过规则模型注入，通过场景模型编排，而不是在行为方法内扩张。

3.2 模型元素规范

3.2.1 行为（Behavior）

属性名	类型	说明
id	String	行为唯一标识，建议格式：{EntityAlias}_{ActionName}
name	String	行为业务名称（中文动宾短语）
ownerEntity	EntityRef	行为所属对象
behaviorType	Enum	COMMAND（指令，改变状态）/ QUERY（查询，只读）/ EVENT_HANDLER（事件响应处理器）
triggerType	Enum	USER_ACTION（用户触发）/ SYSTEM（系统定时）/ EVENT（事件订阅）/ EXTERNAL（外部接口调用）
preconditions	Condition[]	前置条件集合，全部满足才可执行
postconditions	StateChange[]	执行后的状态变更描述
appliedRules	RuleRef[]	调用的规则模型引用
requiredPermissions	PermissionRef[]	执行所需权限（引用M5主体模型）
producedEvents	Event[]	执行成功后产生的事件
qualityAnnotation	QoSRef	质量约束标注（引用M7）
compensationRef	CompensationRef	关联的补偿行为（引用M6）

3.2.2 事件（Event）— 内嵌于行为

属性名	类型	说明
eventId	String	事件唯一标识，建议格式：{Entity}.{State}_{Past}，如 Order.PaymentConfirmed
eventName	String	事件业务名称（中文）
triggerCondition	String	触发事件的条件表达式
payload	FieldRef[]	事件携带的对象字段引用
subscribers	BehaviorRef[]	已知订阅者（可选，用于文档化）
ordering	Enum	事件顺序语义：AT_LEAST_ONCE / EXACTLY_ONCE / BEST_EFFORT

3.2.3 前置/后置条件（Condition / StateChange）

使用简洁的谓词表达式语法，避免引入完整编程语言的复杂度：

前置条件示例：order.status == '待支付' AND order.totalAmount > 0
状态变更示例：order.status = '已支付' | order.paidAt = NOW()
支持跨实体引用：stock.availableQty >= orderItem.quantity

3.3 YAML 元文件模板

# M2 行为模型元文件 - behavior-model.yaml
model_type:BEHAVIOR
version:"1.0"
domain:"订单管理"

behaviors:
-id:Order_ConfirmPayment
    name:确认订单支付
    ownerEntity:ORD-001
    behaviorType:COMMAND
    triggerType:USER_ACTION
    preconditions:
      -"order.status == '待支付'"
      -"order.totalAmount > 0"
    postconditions:
      -field:order.status
        setValue:"已支付"
      -field:order.paidAt
        setValue:NOW()
    appliedRules:
      -RULE-PAY-001   # 支付金额校验规则
      -RULE-FRAUD-001# 风控检查规则
    requiredPermissions:
      -PERM-ORDER-PAY
    producedEvents:
      -eventId:Order.PaymentConfirmed
        eventName:订单支付已确认
        triggerCondition:"postcondition.success == true"
        payload:[orderId,totalAmount,paidAt,userId]
        ordering:EXACTLY_ONCE
    qualityAnnotation:QA-ORDER-001
    compensationRef:COMP-Order_ConfirmPayment

-id:Inventory_DeductStock
    name:扣减库存
    ownerEntity:INV-001
    behaviorType:COMMAND
    triggerType:EVENT
    preconditions:
      -"stock.availableQty >= orderItem.quantity"
    postconditions:
      -field:stock.availableQty
        setValue:"stock.availableQty - orderItem.quantity"
      -field:stock.lockedQty
        setValue:"stock.lockedQty + orderItem.quantity"
    appliedRules:
      -RULE-INV-001   # 库存扣减幂等规则
    producedEvents:
      -eventId:Inventory.StockDeducted
        eventName:库存已扣减
        triggerCondition:"postcondition.success == true"
        payload:[productId,deductedQty,remainingQty]
        ordering:EXACTLY_ONCE
    compensationRef:COMP-Inventory_DeductStock

第四章 M3 规则模型

4.1 设计目标与边界

规则模型专注于可复用的解耦业务规则，是从行为逻辑中分离出来的独立关切。其核心价值在于：同一规则可以被多个行为引用，规则变更不影响行为定义。

重要边界说明：参照完整性约束（外键约束、唯一约束等）不在规则模型中定义，而是归属M1对象模型。规则模型处理的是业务逻辑层面的约束，而非数据结构层面的约束。

4.2 规则分类体系

规则类型	说明
验证规则（Validation Rule）	判断输入数据是否符合业务要求，返回 true/false，不改变状态
计算规则（Calculation Rule）	根据输入参数计算并返回结果值，如计算运费、折扣金额
推导规则（Derivation Rule）	基于已知属性推导出其他属性值，如根据级别推导权限范围
转换规则（Transformation Rule）	将一种数据格式转换为另一种，适用于外部系统集成场景
风控规则（Risk Rule）	评估业务风险，返回风险等级或通过/拒绝决策（可接入外部规则引擎）

4.3 模型元素规范

属性名	类型	说明
id	String	规则唯一标识，建议格式：RULE-{Domain}-{Seq}
name	String	规则业务名称
ruleType	Enum	VALIDATION / CALCULATION / DERIVATION / TRANSFORMATION / RISK
description	String	规则的业务逻辑说明
inputParams	Param[]	输入参数定义（名称、类型、来源实体字段）
outputType	DataType	返回值类型
expression	String	规则表达式（支持伪代码或DSL，不限定具体语言）
reusedBy	BehaviorRef[]	引用本规则的行为列表（反向追踪）
externalEngine	String	若委托外部规则引擎，填写引擎名称（如 Drools, OPA）
version	String	规则版本，支持规则的独立版本管理

4.4 YAML 元文件模板

# M3 规则模型元文件 - rule-model.yaml
model_type:RULE
version:"1.0"
domain:"订单管理"

rules:
-id:RULE-PAY-001
    name:支付金额一致性验证
    ruleType:VALIDATION
    description:验证支付金额与订单总额一致，允许误差0.01元
    inputParams:
      -name:paymentAmount
        type:Decimal
        sourceField:Payment.amount
      -name:orderAmount
        type:Decimal
        sourceField:Order.totalAmount
    outputType:Boolean
    expression:|
      ABS(paymentAmount - orderAmount) <= 0.01
    version:"1.2"
    reusedBy:
      -Order_ConfirmPayment
      -Payment_Reconcile

-id:RULE-SHIP-001
    name:运费计算规则
    ruleType:CALCULATION
    description:根据包裹重量和目的地区域计算运费
    inputParams:
      -name:weight
        type:Decimal
      -name:destRegion
        type:String
    outputType:Decimal
    expression:|
      IF destRegion IN ['华东', '华南'] THEN
        IF weight <= 1 THEN 8 ELSE 8 + (weight - 1) * 2
      ELSE
        IF weight <= 1 THEN 12 ELSE 12 + (weight - 1) * 3
    version:"2.0"

-id:RULE-FRAUD-001
    name:支付风控检查
    ruleType:RISK
    description:对支付行为进行风险评估，超过阈值需人工审核
    inputParams:
      -name:userId
        type:String
      -name:paymentAmount
        type:Decimal
      -name:deviceFingerprint
        type:String
    outputType:Enum# PASS / REVIEW / REJECT
    externalEngine:"RiskEngineService"
    version:"3.1"

第五章 M4 场景模型

5.1 双层场景体系

场景模型分为两个层次，形成层次化的业务描述：

层次	说明
业务流程（Business Process）	跨多个业务用例的大粒度流程，描述完整的业务价值链，如"订单履约流程"。由多个业务用例串联或并联组成。
业务用例（Business Use Case）	单一业务场景，对应一次完整的用户意图达成，如"客户下单"。由对象行为调用序列和事件链组成。

5.2 事件链编排语义

场景模型的核心是事件链编排，需要明确表达以下语义：

编排语义	说明
顺序（Sequence）	A行为完成后执行B行为
并行（Parallel / AND-Split）	同时触发多个行为，全部完成后继续
聚合等待（AND-Join）	等待多个事件全部到达后触发下一步
选择分支（XOR-Split）	根据条件选择一个分支执行
事件等待（Event-Based Gateway）	等待特定事件到来再继续
超时处理（Timer Event）	等待超时后触发补偿或替代路径

5.3 模型元素规范

5.3.1 业务用例（UseCase）

属性名	类型	说明
id	String	用例唯一标识
name	String	用例名称（动宾短语，如"客户确认支付"）
actors	ActorRef[]	参与的主体（引用M5）
primaryFlow	FlowStep[]	主成功路径步骤列表
alternativeFlows	AltFlow[]	替代路径（条件分支）
exceptionFlows	ExcFlow[]	异常路径（引用M6）
preconditions	String[]	用例启动前提条件
postconditions	String[]	用例成功完成后的系统状态
qualityAnnotation	QoSRef	端到端质量要求（引用M7）

5.3.2 流程步骤（FlowStep）

属性名	类型	说明
stepId	String	步骤标识
stepType	Enum	BEHAVIOR_CALL（行为调用）/ EVENT_EMIT（事件发布）/ EVENT_WAIT（事件等待）/ GATEWAY（网关）/ EXTERNAL_CALL（外部调用）
behaviorRef	BehaviorRef	当stepType=BEHAVIOR_CALL时的行为引用
gatewayType	Enum	当stepType=GATEWAY时：AND_SPLIT / AND_JOIN / XOR_SPLIT / EVENT_GATEWAY
condition	String	XOR分支条件表达式
timeout	Duration	步骤超时时间，超时后触发compensationRef
nextSteps	StepRef[]	后继步骤（支持多个，用于并行和分支）

5.3.3 业务流程（Business Process）

属性名	类型	说明
id	String	流程唯一标识
name	String	流程名称
useCases	UseCaseRef[]	组成该流程的用例列表
orchestration	FlowStep[]	用例间的编排步骤（同FlowStep规范）
sagaBoundary	SagaRef	该流程对应的Saga边界（引用M6）

5.4 YAML 元文件模板

# M4 场景模型元文件 - scenario-model.yaml
model_type:SCENARIO
version:"1.0"
domain:"订单管理"

use_cases:
-id:UC-ORDER-003
    name:客户确认支付
    actors:
      -ACTOR-CUSTOMER
      -ACTOR-PAYMENT-GATEWAY
    preconditions:
      -"order.status == '待支付'"
      -"当前用户是订单所有人"
    postconditions:
      -"order.status == '已支付'"
      -"库存已完成扣减"
    primaryFlow:
      -stepId:S01
        stepType:BEHAVIOR_CALL
        behaviorRef:Order_ConfirmPayment
        timeout:PT30S
        nextSteps:[S02]
      -stepId:S02
        stepType:EVENT_WAIT
        waitForEvent:Order.PaymentConfirmed
        timeout:PT60S
        nextSteps:[S03]
        onTimeout:S_TIMEOUT
      -stepId:S03
        stepType:GATEWAY
        gatewayType:AND_SPLIT
        nextSteps:[S04,S05]
      -stepId:S04
        stepType:BEHAVIOR_CALL
        behaviorRef:Inventory_DeductStock
        nextSteps:[S06]
      -stepId:S05
        stepType:BEHAVIOR_CALL
        behaviorRef:Notification_SendPaymentSuccess
        nextSteps:[S06]
      -stepId:S06
        stepType:GATEWAY
        gatewayType:AND_JOIN
        waitFor:[S04,S05]
        nextSteps:[S07]
      -stepId:S07
        stepType:BEHAVIOR_CALL
        behaviorRef:Order_TriggerFulfillment
    alternativeFlows:
      -id:ALT-01
        triggerAt:S01
        condition:"riskRule.result == 'REVIEW'"
        steps:
          -stepId:A01
            stepType:BEHAVIOR_CALL
            behaviorRef:Order_PendingRiskReview
    exceptionFlows:
      -id:EXC-01
        triggerAt:S_TIMEOUT
        compensationRef:COMP-UC-ORDER-003
    qualityAnnotation:QA-ORDER-003

business_processes:
-id:BP-FULFILL-001
    name:订单履约流程
    useCases:
      -UC-ORDER-003# 确认支付
      -UC-ORDER-004# 发货处理
      -UC-ORDER-005# 物流跟踪
    sagaBoundary:SAGA-FULFILL-001

第六章 M5 主体模型

6.1 设计目标

主体模型解决"谁能做什么"的问题，是行为模型与对象模型之外的独立关切。采用RBAC（基于角色的访问控制）为基础，支持ABAC（基于属性的访问控制）扩展。（本文件为@人月聊IT原创整理，转载注明出处）

设计决策：权限定义不内嵌于行为模型（避免耦合），而是在行为模型中声明 requiredPermissions，在主体模型中定义权限的授予关系。这样角色权限的变化不影响行为模型定义。

6.2 模型层次

层次	说明
参与者（Actor）	与系统交互的主体，分为：人类用户（Human）、系统账户（System）、外部系统（External）
角色（Role）	权限的集合单元，一个参与者可拥有多个角色，角色支持继承
权限（Permission）	对特定对象或行为的操作授权，粒度到行为级别
权限组（PermissionGroup）	权限的分组管理，便于批量授予
外部实体（ExternalEntity）	外部系统的边界定义，包括接口契约、协议、数据契约

6.3 模型元素规范

6.3.1 参与者（Actor）

属性名	类型	说明
actorId	String	主体唯一标识
actorType	Enum	HUMAN / SYSTEM / EXTERNAL
roles	RoleRef[]	拥有的角色列表
attributes	Map	主体属性（用于ABAC条件评估，如 department, level）
externalContract	Contract	当actorType=EXTERNAL时的接口契约定义
└─ protocol	Enum	接口协议：REST / SOAP / MQ / gRPC / SFTP
└─ dataFormat	Enum	数据格式：JSON / XML / CSV / Binary
└─ authMethod	Enum	认证方式：API_KEY / OAuth2 / mTLS / NONE
└─ timeoutMs	Integer	调用超时限制（毫秒）
└─ retryPolicy	RetryRef	重试策略引用（引用M6）

6.3.2 角色（Role）

属性名	类型	说明
roleId	String	角色唯一标识
name	String	角色名称
inheritsFrom	RoleRef[]	继承的父角色（支持多继承）
permissions	PermissionRef[]	直接授予的权限列表
permissionGroups	GroupRef[]	授予的权限组

6.3.3 权限（Permission）

属性名	类型	说明
permissionId	String	权限标识，建议格式：PERM-{Domain}-{Action}
targetType	Enum	授权目标类型：BEHAVIOR（行为）/ ENTITY（实体数据）
targetRef	Ref	授权目标引用
dataScope	Enum	数据范围：ALL / OWN / DEPT / CUSTOM
abacCondition	String	ABAC条件表达式，如 actor.dept == resource.dept

6.4 YAML 元文件模板

# M5 主体模型元文件 - actor-model.yaml
model_type:ACTOR
version:"1.0"
domain:"订单管理"

actors:
-actorId:ACTOR-CUSTOMER
    name:客户
    actorType:HUMAN
    roles:
      -ROLE-CUSTOMER

-actorId:ACTOR-PAYMENT-GATEWAY
    name:支付网关
    actorType:EXTERNAL
    externalContract:
      protocol:REST
      dataFormat:JSON
      authMethod:OAuth2
      timeoutMs:30000
      retryPolicy:RETRY-EXTERNAL-001

roles:
-roleId:ROLE-CUSTOMER
    name:普通客户
    permissions:
      -PERM-ORDER-CREATE
      -PERM-ORDER-PAY
      -PERM-ORDER-CANCEL-OWN

-roleId:ROLE-ORDER-ADMIN
    name:订单管理员
    inheritsFrom:[ROLE-CUSTOMER]
    permissions:
      -PERM-ORDER-CANCEL-ALL
      -PERM-ORDER-REFUND

permissions:
-permissionId:PERM-ORDER-PAY
    targetType:BEHAVIOR
    targetRef:Order_ConfirmPayment
    dataScope:OWN
    abacCondition:"actor.userId == order.customerId"

-permissionId:PERM-ORDER-CANCEL-ALL
    targetType:BEHAVIOR
    targetRef:Order_Cancel
    dataScope:ALL

第七章 M6 异常补偿模型

7.1 为什么需要独立的异常补偿模型

在EDA事件驱动架构下，长流程由多个异步步骤串联完成。当中间某个步骤失败时，传统数据库事务回滚不再适用，需要通过"补偿行为"来撤销已完成的步骤。这一复杂度需要在建模阶段明确表达，否则会成为实现阶段的隐性债务。

7.2 异常分类体系

异常类型	处理策略
业务异常（BusinessException）	违反业务规则导致的可预期失败，如库存不足、余额不足。处理策略：直接终止并返回业务错误，通常不需要补偿。
技术异常（TechnicalException）	系统层面的临时故障，如网络超时、数据库不可用。处理策略：重试 + 幂等保护。
业务冲突（ConflictException）	并发操作导致的业务状态冲突，如超卖。处理策略：乐观锁冲突检测 + 重试或拒绝。
补偿失败（CompensationFailure）	补偿操作本身失败，需人工介入。处理策略：触发人工处理流程 + 告警。

7.3 Saga 协调模型

对于跨多个对象/服务的长流程，采用Saga模式管理补偿：

概念	说明
Saga定义	一组需要保持最终一致性的行为序列，每个步骤都有对应的补偿步骤
编排模式（Orchestration）	由集中的Saga协调器（场景模型中定义）控制执行顺序和补偿触发
补偿顺序	逆序执行补偿，即最后执行的步骤最先补偿（LIFO）
幂等性要求	所有补偿行为必须声明幂等性，支持多次安全执行

7.4 模型元素规范

属性名	类型	说明
compensationId	String	补偿定义唯一标识
targetBehavior	BehaviorRef	被补偿的目标行为
compensationBehavior	BehaviorRef	执行补偿的行为引用（也在M2中定义）
exceptionTypes	Enum[]	触发此补偿的异常类型列表
retryPolicy.maxRetries	Integer	最大重试次数（用于TechnicalException）
retryPolicy.backoffType	Enum	退避策略：FIXED / EXPONENTIAL / JITTER
retryPolicy.initialDelayMs	Integer	初始重试延迟（毫秒）
fallback	Enum	重试耗尽后的兜底策略：MANUAL_PROCESS / DEAD_LETTER / REJECT
idempotencyKey	String	幂等键构成字段表达式，确保补偿操作安全重复执行
sagaRef	SagaRef	所属Saga范围引用

7.5 YAML 元文件模板

# M6 异常补偿模型元文件 - compensation-model.yaml
model_type:COMPENSATION
version:"1.0"
domain:"订单管理"

compensations:
-compensationId:COMP-Order_ConfirmPayment
    targetBehavior:Order_ConfirmPayment
    compensationBehavior:Order_ReversePayment
    exceptionTypes:[TechnicalException,CompensationFailure]
    retryPolicy:
      maxRetries:3
      backoffType:EXPONENTIAL
      initialDelayMs:500
      maxDelayMs:10000
    fallback:DEAD_LETTER
    idempotencyKey:"orderId + '_' + paymentId"

-compensationId:COMP-Inventory_DeductStock
    targetBehavior:Inventory_DeductStock
    compensationBehavior:Inventory_RestoreStock
    exceptionTypes:[TechnicalException]
    retryPolicy:
      maxRetries:5
      backoffType:EXPONENTIAL
      initialDelayMs:200
    fallback:MANUAL_PROCESS
    idempotencyKey:"orderId + '_' + productId + '_' + deductionId"

sagas:
-sagaId:SAGA-FULFILL-001
    name:订单履约Saga
    steps:
      -stepOrder:1
        behavior:Order_ConfirmPayment
        compensation:COMP-Order_ConfirmPayment
      -stepOrder:2
        behavior:Inventory_DeductStock
        compensation:COMP-Inventory_DeductStock
      -stepOrder:3
        behavior:Logistics_CreateShipment
        compensation:COMP-Logistics_CreateShipment
    compensationOrder:LIFO
    onCompensationFailure:MANUAL_PROCESS

第八章 M7 质量约束模型

8.1 设计目标

质量约束模型不独立承载功能，而是以"标注"（Annotation）的形式挂载到行为模型和场景模型上，将非功能性需求（NFR）与功能定义绑定，确保实现阶段不遗漏质量要求。（本文件为@人月聊IT原创整理，转载注明出处）

8.2 质量维度框架

质量维度	关键指标
性能（Performance）	响应时间SLA、吞吐量要求、最大并发数
可靠性（Reliability）	可用性目标（SLA %）、故障恢复时间（RTO/RPO）
一致性（Consistency）	数据一致性级别：强一致 / 最终一致 / 读自写一致
并发安全（Concurrency）	并发冲突处理策略：乐观锁 / 悲观锁 / 无锁队列
可审计（Auditability）	是否需要操作日志、变更历史追踪
幂等性（Idempotency）	接口是否需要幂等保护及幂等键设计

8.3 模型元素规范（QoS Annotation）

属性名	类型	说明
qaId	String	质量约束标注唯一标识
appliesTo	Ref[]	标注目标：行为引用或场景用例引用
performance.maxResponseMs	Integer	最大响应时间（毫秒）
performance.targetTps	Integer	目标吞吐量（每秒事务数）
performance.maxConcurrency	Integer	最大并发执行数
reliability.availabilityTarget	String	可用性目标，如 "99.9%"
reliability.rtoMinutes	Integer	恢复时间目标（分钟）
reliability.rpoMinutes	Integer	恢复点目标（分钟）
consistency.level	Enum	STRONG / EVENTUAL / READ_YOUR_WRITES
concurrency.strategy	Enum	OPTIMISTIC_LOCK / PESSIMISTIC_LOCK / QUEUE_SERIALIZE
auditRequired	Boolean	是否需要操作审计日志
idempotencyRequired	Boolean	是否需要幂等性保护

8.4 YAML 元文件模板

# M7 质量约束模型元文件 - quality-model.yaml
model_type:QUALITY
version:"1.0"
domain:"订单管理"

quality_annotations:
-qaId:QA-ORDER-001
    name:支付确认接口质量要求
    appliesTo:
      -Order_ConfirmPayment
    performance:
      maxResponseMs:3000
      targetTps:500
      maxConcurrency:200
    reliability:
      availabilityTarget:"99.95%"
      rtoMinutes:5
      rpoMinutes:1
    consistency:
      level:STRONG
    concurrency:
      strategy:OPTIMISTIC_LOCK
    auditRequired:true
    idempotencyRequired:true

-qaId:QA-ORDER-003
    name:下单用例端到端质量要求
    appliesTo:
      -UC-ORDER-003
    performance:
      maxResponseMs:5000   # 端到端完成时间
    reliability:
      availabilityTarget:"99.9%"
    consistency:
      level:EVENTUAL        # 库存扣减允许最终一致
    auditRequired:true

第九章传统需求覆盖度分析

9.1 与传统需求工程的映射

传统需求维度	本框架覆盖	承载模型
数据需求 / 概念模型	✅ 完整覆盖	M1 对象模型
功能需求（细粒度）	✅ 完整覆盖	M2 行为模型
业务规则	✅ 完整覆盖	M3 规则模型
业务流程 / 用例	✅ 完整覆盖	M4 场景模型
访问控制 / 权限	✅ 完整覆盖	M5 主体模型
异常处理 / 补偿	✅ 完整覆盖	M6 异常补偿模型
非功能性需求（NFR）	✅ 完整覆盖	M7 质量约束模型
外部系统集成	✅ 完整覆盖	M5 ExternalEntity + M2 EXTERNAL_CALL
事件 / 集成需求	✅ 完整覆盖	M2 Event + M4 事件链编排
参照完整性约束	✅ 完整覆盖	M1 ReferentialConstraint
并发冲突处理	✅ 完整覆盖	M6 ConflictException + M7 并发策略
UI交互（明确排除）	⭕ 框架外	不在本方案范围内

9.2 框架整体覆盖评估

核心优势

语义驱动，业务与技术高度一致
正交分层，各模型可独立演进
事件链使复杂流程可视化
NFR通过标注机制内嵌需求
异常路径与正常路径对等表达
外部系统边界通过ExternalEntity显式建模
规则独立版本管理，支持热更新

已知局限（框架外）

不覆盖UI/UX交互需求（明确排除）
报表/BI查询需求需独立补充
基础设施部署需求需独立说明
多语言/国际化需求框架外

第十章实施指南与最佳实践

10.1 建模顺序推荐

七个模型之间存在依赖，建议按以下顺序建模，避免循环依赖：

阶段	建模对象	说明
①	M1 对象模型	从业务词汇表开始，识别核心实体、属性和关联，先不考虑行为
②	M5 主体模型（Actor部分）	识别系统参与者和角色，此时只定义角色，权限后续补充
③	M3 规则模型	梳理独立于具体行为的业务规则，可以和业务专家协作完成
④	M2 行为模型	为每个对象定义行为，引用规则，定义产生的事件
⑤	M5 主体模型（权限部分）	为行为绑定权限，定义外部实体接口契约
⑥	M6 异常补偿模型	为关键行为定义补偿策略，识别Saga边界
⑦	M4 场景模型	组装业务用例和流程，包含正常路径和异常分支
⑧	M7 质量约束模型	为关键行为和场景标注NFR，与架构团队对齐

10.2 模型评审检查清单

M1 对象模型评审

[ ] 所有实体是否有明确的生命周期状态定义？
[ ] 关联关系的基数是否符合业务实际？
[ ] 参照完整性约束是否覆盖了所有跨实体约束？
[ ] 是否存在循环依赖的实体关系？（如有，是否合理）
[ ] 实体alias是否与代码命名保持一致？

M2 行为模型评审

[ ] 每个行为是否真正原子化，只操作一个对象？
[ ] 前置条件是否完整覆盖了行为可执行的业务前提？
[ ] 后置状态变更是否完整描述了行为的全部副作用？
[ ] 每个COMMAND行为是否定义了对应的补偿行为引用？
[ ] 事件payload是否包含了下游订阅者所需的全部字段？

M3 规则模型评审

[ ] 规则是否真正可复用（被2个以上行为引用才值得独立）？
[ ] 规则表达式是否无副作用（不改变系统状态）？
[ ] 规则版本是否独立管理，与行为版本解耦？

M4 场景模型评审

[ ] 是否覆盖了主成功路径和所有可预期的替代路径？
[ ] 并行执行的步骤是否定义了AND-JOIN聚合条件？
[ ] 每个步骤是否定义了超时处理策略？
[ ] Saga边界是否清晰，补偿顺序是否正确定义？
[ ] 用例前置/后置条件是否与M2行为的前后置条件一致？

M5 主体模型评审

[ ] 外部系统是否定义了接口契约（协议、超时、重试）？
[ ] ABAC条件是否覆盖了数据隔离需求（如多租户）？
[ ] 角色继承关系是否符合最小权限原则？

M6 异常补偿模型评审

[ ] 所有写操作行为是否都有补偿行为对应？
[ ] 补偿行为是否声明了幂等性保证？
[ ] 死信队列的后续处理流程是否有对应的运维规程？

M7 质量约束模型评审

[ ] 核心业务路径是否都有性能SLA标注？
[ ] 一致性级别选择是否经过权衡（强一致 vs 可用性）？
[ ] 审计要求是否覆盖了合规和安全的需要？

10.3 文件命名与版本管理建议

建议将七个模型元文件纳入版本控制（Git），采用如下目录约定：

models/
├── {domain}/
│   ├── m1-object-model.yaml
│   ├── m2-behavior-model.yaml
│   ├── m3-rule-model.yaml
│   ├── m4-scenario-model.yaml
│   ├── m5-actor-model.yaml
│   ├── m6-compensation-model.yaml
│   └── m7-quality-model.yaml
├── shared/
│   ├── m3-shared-rules.yaml    # 跨域复用规则
│   └── m5-global-roles.yaml    # 全局角色定义
└── CHANGELOG.md

版本管理约定：

每个元文件内部维护自己的 version 字段
跨模型的破坏性变更（如实体删除、行为签名变更）需要在 CHANGELOG.md 中记录
规则模型支持独立版本，允许热更新而不触发其他模型变更

10.4 工具链建议

工具场景	建议方案
模型编辑	VS Code + YAML插件 + 自定义JSON Schema校验，保证模型文件的结构合规性
可视化	将YAML解析后生成PlantUML或Mermaid图表，可集成到CI/CD流水线自动生成文档
一致性检查	编写校验脚本：检查行为模型中的entityRef是否都存在于对象模型中
代码生成	基于模型元文件生成：实体类骨架、接口签名、事件常量、权限枚举等
变更影响分析	当M1实体变更时，自动分析影响的M2行为、M3规则、M4场景
模型验证CI	每次PR合并前运行模型一致性检查，防止引用悬空（dangling reference）

10.5 与实现层的映射建议

本框架是需求/设计层的语义模型，与实现技术的映射建议如下：

本体模型元素	实现层对应
M1 实体	JPA Entity / Prisma Model / Mongoose Schema
M1 关联关系	ORM关联配置 / 数据库外键
M2 行为（COMMAND）	Application Service Method / Use Case Handler
M2 行为（QUERY）	Query Service / Repository Query Method
M2 事件	Domain Event / Message Topic
M3 规则	Domain Service / Policy Object / Rule Engine Rule
M4 场景（流程）	Saga Orchestrator / Process Manager
M5 主体模型	Spring Security / Casbin / OPA Policy
M6 异常补偿	Saga Compensating Transaction / Dead Letter Queue
M7 质量标注	SLA监控指标 / 限流配置 / 锁策略配置

附录术语对照表

术语	定义
本体（Ontology）	对某个领域中概念及其关系的形式化表达，借鉴自知识工程和OWL规范
原子行为（Atomic Behavior）	不可再分的最小行为单元，只操作单一对象，产生确定性副作用
事件链（Event Chain）	由行为产生事件、事件触发新行为形成的异步处理链路
EDA（Event-Driven Architecture）	事件驱动架构，通过消息事件实现组件间的松耦合
Saga模式	分布式事务的补偿模式，将长事务分解为一系列本地事务，每步有对应补偿
RBAC	基于角色的访问控制（Role-Based Access Control）
ABAC	基于属性的访问控制（Attribute-Based Access Control），比RBAC更细粒度
NFR（Non-Functional Requirement）	非功能性需求，包括性能、可靠性、安全性、可维护性等
QoS Annotation	质量服务标注，将NFR以标注形式绑定到功能元素上
幂等性（Idempotency）	操作执行一次与执行多次产生相同结果的特性，分布式系统的关键要求
RTO（Recovery Time Objective）	恢复时间目标，系统故障后允许的最长恢复时间
RPO（Recovery Point Objective）	恢复点目标，系统故障后允许的最大数据丢失时间窗口
AND-Join	流程编排中等待多个并行分支全部完成的聚合节点
XOR-Split	流程编排中根据条件选择唯一一个分支执行的网关节点
Dead Letter	无法处理的消息被放入死信队列，等待人工干预或后续处理
LIFO	后进先出（Last In First Out），Saga补偿的默认执行顺序
Dangling Reference	悬空引用，模型中引用了不存在的目标，需通过CI校验防止
OWL	网络本体语言（Web Ontology Language），W3C标准的语义本体描述语言

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2026-03-13，如有侵权请联系 cloudcommunity@tencent.com 删除

对象

本文分享自人月聊IT 微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！