业务建模的层层展开：价值模型→服务蓝图→业务流程图

业务架构建模按”从抽象到具体”的顺序层层展开，每一层都是对上一层的进一步细化。价值模型是最抽象的一层，负责呈现企业战略的价值链路——业界常用波特价值链模型（把企业内外活动分为基本性活动和支持性活动）或价值流模型（[[从面向过程到面向对象的认知转变|功能模型]]的一种特例，专门体现对客户的价值部分，如PDCA计划-执行-检查-行动就是一种价值流模型）；实践中通常先把企业的产品/服务按核心类和支撑类梳理清楚，再为每一类分别画出对应的价值流图（比如资产管理类企业，投资管理服务是核心类别，价值流包括研究数据、投资组合、交易指令；产品管理服务是支撑类别，价值流包括研究产品、募集产品、投资产品、管理产品、退出产品）。服务蓝图是第二层，价值模型只关注价值本身如何流转，服务蓝图则进一步展开”企业最终实现这个价值需要哪些实体”——这些实体包括人员、生产机器、工具、软件系统等，每个实体都要提供相应的业务功能来支撑价值的实现。业务流程图是第三层，对服务蓝图里的业务功能做展开描述——每个业务功能对应一个端到端的业务流程，由某个行为体（人或系统）发起，由一系列任务或步骤组成；绘制业务流程时还要同时梳理出相关的业务规则（对应需求阶段里”会变化的需求”部分，指明在什么条件下能执行特定任务，比如”研报模板需要具备灵活的可配置性”就是一条业务规则）。领域模型是业务架构模型里需要重点关注的跨领域模型——虽然DDD里也提到领域模型，但那更多指向限界上下文内部（即微服务内部）的模型，而业务架构关注的跨领域模型，从企业战略角度看往往具有更高的价值。可迁移启发：拿到一份业务架构文档时，先确认它交代清楚了这条链路上的哪几层——只有价值模型没有服务蓝图，说明还没有落到”谁去实现这个价值”；只有服务蓝图没有业务流程图，说明还没有说清楚”这些实体具体怎么协作完成任务”；这个层层展开的顺序本身就是一份现成的完整性检查清单。

结构图：

flowchart TB
  V["价值模型(最抽象)<br/>波特价值链/价值流模型<br/>按核心类/支撑类分别绘制"]
  V --> S["服务蓝图<br/>展开实现价值所需的实体<br/>(人员/机器/工具/软件系统)"]
  S --> B["业务流程图<br/>展开每个业务功能的端到端流程<br/>+梳理对应的业务规则"]
  D["领域模型(跨领域)<br/>区别于DDD限界上下文内部模型"]