202605更新《软件方法》第3章组织价值和流程改进-夜雨聆风

202605更新《软件方法》第3章组织价值和流程改进

DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

一样的月光，一样的照着新店溪。

《一样的月光》；词：吴念真、罗大佑，曲：李寿全，唱：苏芮；1982

3.1 从两个视角研究组织

有了愿景，我们知道目标组织负责人对目标组织的现状的某些指标不满意。接下来，就需要研究目标组织，弄清楚之所以这些指标比较差，到底是组织的哪些环节造成的。

我们从内和外两个视角来研究组织。从外部看，组织提供了一些价值，可以用业务用例图表示。从内部看，组织由一些系统组成，组织的价值通过这些系统之间的协作，也就是所谓的业务流程来实现。这可以用业务序列图来表示。

图3-1展示了某餐馆的外和内两个视角。

图3-1 某餐馆的外和内两个视角

3.2 建模步骤A-3 业务用例模型

3.2.1 用例的历史

1970年代，Ivar Jacobson对AXE交换机的成功做出了巨大贡献。1980年代中期，Ivar Jacobson花了很多精力来思考过去十多年在爱立信的工作方法。他造了一个瑞典语术语anvendningsfall，大意是“使用的情况（situation of usage）”，翻译成英文就是“用例（use case）”。

Ivar Jacobson在OOPSLA ’87上发表文章Object-oriented development in an industrial environment，用例正式作为学术概念出现。

在1992年出版的Object-Oriented Software Engineering: A Use Case Driven Approach书中，Ivar Jacobson更全面地阐述了用例驱动的面向对象软件工程，然后1994年的The Object Advantage: Business Process Reengineering With Object Technology书中，他将用例于对组织建模，也就是业务用例（business use case）。

Alistair Cockburn在2000年的书Writing Effective Use Cases中，给用例加上了涉众和利益（stakeholders and interests）的内容，为用例规约的内容提供了依据。到这一步，用例的理论框架基本成型。

此后的二十多年，本书作者一直在将用例用于组织建模和系统需求实践，在不断思考用例正确使用方式的过程中，深化和拓展了用例的知识体系。

3.2.2 用例的概念

用例（use case）是主体（subject）可以提供而且满足涉众（stakeholder）期望的价值，通过主体和执行者（actor）之间的动作序列达到。

图3-2 用例

当主体是系统时，用例是系统用例，表达系统的价值以及围绕这个价值的系统需求集合。这是用例最常用的场合。

图3-3表达了“网约车平台”这个系统的用例：

图3-3 网约车平台的用例

这个用例会将一些相关的系统需求组织起来，如图3-4：

图3-4 系统用例背后的系统需求

当主体是组织时，用例是业务用例，表达一个组织为其他组织提供的价值。

图3-5表达了医院的用例：

图3-5 医院的用例

同样，一个业务用例隐含了组织的若干流程，如图3-6：

图3-6 业务用例背后的组织流程

图3-5和图3-6中的小人和椭圆带了一道斜杠，这是构造型<<Business Actor>>（业务执行者）和<<Business Use Case>>（业务执行者）的图形表示，意思是“我是某个外部组织”、“我是某个组织的用例”。

如果您使用的建模工具没有这个图形，可以用执行者的小人图标加上文本构造型<<Business Actor>>、<<Business Use Case>>取代，用中文<<业务执行者>>、<<业务用例>>也可以。

不加构造型也无所谓，因为边界框中的“医院”这个名称表明主体是“医院”，只要在模型的某个地方说明了“医院”是一个组织（严格来说是组织规格），“医院”的执行者、用例自然是业务执行者和业务用例。当然，如果建模人员或辅助建模用的AI能够从“医院”二字判断出它是一个组织，而且毫无例外，不需要说明也可以。

从这一点上看，“业务执行者”和“业务用例”是推导和计算的结果，不是模型必须记录的内容。如果允许直接编辑这样的内容，就有逻辑不一致的风险。

如图3-7所示，研究对象是一个系统，执行者却是“业务执行者”的构造型。这在逻辑上是冲突的，但目前的建模工具可以画出这样的图。

图3-7 “患者”是系统的执行者，却有“业务执行者”构造型

可能读者在这里会感到困惑，图3-6的“患者”有“业务执行者”构造型，怎么就不能搬到图3-7？

首先，这两个“患者”含义不同，一个是个人组织，一个是人脑系统，详见第2章；其次，即使含义一样，某个东西在A场景下能扮演的角色，在B场景下未必能扮演。

3.2.3 “业务”一词的含糊

说到“业务执行者”、“业务用例”时，有必要说一下“业务”这个词的含糊。

“业务（business）”这个词在软件开发组织中使用得很频繁。经常可以听到“我是一名业务架构师”、“我们要了解业务”等等话语，但是往往说话的人未必真的理解话语中的“业务”具体指什么。

（1）有时候“业务”的含义是“领域”，更严谨的说法是“核心域”或“问题域”。

例如，一个餐馆系统，订单和菜品的关系属于“业务知识”，折扣的计算规则属于“业务规则”，如图3-8：

图3-8 展示餐饮领域“业务”知识的类图

此时，和“业务”一词相对应的是“技术”。

开发人员假装谦虚“我是做技术的，业务不太懂唉”，就是这个意思。甚至有的开发人员在潜意识里是这样划分的：

我懂且我感兴趣的知识→技术；（我是一名Java程序员，Java编码是技术）

我懂但不感兴趣的知识→业务；（下单、收银、配送我懂一些，但不感兴趣，这些是业务）

我不懂但感兴趣的知识→高科技；（我不懂深度学习，但很感兴趣，哇塞，高科技）

我不懂且不感兴趣的东东→忽悠。（我不懂UML建模，也不感兴趣，妈的，忽悠）

（2）有时候“业务”的含义是“组织”或“组织级别”。

例如，“业务建模”说的是组织的建模，“业务用例”说的是组织为其他组织提供的用例，“业务流程”说的是组织内各个系统之间协作的流程。

图3-9，表达了餐馆组织的流程，也就是所谓“业务”流程。

图3-9 餐馆组织的“业务”流程

此时，和“业务”相对应的就是“系统”了，例如图3-9餐馆组织中的人脑系统和非人系统。

如果不了解“业务”的这两个含义的区别，就会导致乱用或者第1章提到的砌词。

“业务用例”就是一个常见的乱用。很多人觉得，我在说用例时没有谈到“技术”嘛，所以用例自然就是“业务”的了！于是，“业务用例”顺口而出。

其实这里的“业务”是“组织”的意思。

Scott Millett在“Patterns, Principles, and Practices of Domain-Driven Design”书中，大量使用了“business use case”，如图3-10。

图3-10 摘自“Patterns, Principles, and Practices of Domain-Driven Design”中译本，《领域驱动设计模式、原理与实践》

从“系统行为”、“应用程序的使用场景”等文字可知，Scott Millett所说的“业务用例”其实是系统用例。另外，他还使用了“业务用户（business user）”这样的砌词——有“非业务用户”吗？

国内领域驱动设计圈子的书也有类似问题，图3-11摘自张逸《解构领域驱动设计》一书：

图3-11 摘自张逸《解构领域驱动设计》

都已经在讨论分层架构、基础设施了，这里的“业务用例”应该是“系统用例”或“用例”。

国内的领域驱动设计圈子其他类似例子，读者可以自行搜“领域驱动设计业务用例”、“DDD 业务用例”。

我也多次想过放弃使用“业务用例”、“业务流程”，改为“组织用例”、“组织流程”，但考虑到“业务”的含义为“组织”的一些用语使用范围已经较广，也进入了主流的建模工具中，例如图3-1、图3-9的序列图就使用了<<business actor>>、<<business worker>>和<<business entity>>的构造型。

因此，本书还是保留了“业务**”的说法，不过会尽量减少使用。例如，本书会说“某组织的流程”、“某组织的用例”，但不会说“某组织的业务流程”、“某组织的业务用例”。

我把一些常用的“业务”用词汇总如图3-12，供读者查阅。不全之处，欢迎读者补充。

“业务”的含义	用词	对应的“非业务”用语
组织、组织级别	业务建模	系统建模
	业务用例	系统用例
	业务执行者	系统执行者
	业务工人	无
	业务实体	系统里的“实体（类）”
	业务流程	无
核心域、问题域、领域	业务逻辑	无
	业务规则	无
	业务知识	技术知识
	业务人员	技术人员
	懂业务	懂技术
含义不明	业务架构	/
错误，不提倡使用	业务需求业务领域业务用户业务系统业务用户领域需求	/

图3-12 “业务”在不同用语中的含义

注意，图3-12中的最右侧一列有许多“无”，但领域驱动设计圈子的一些文章中，经常会出现相应的造词，例如“技术逻辑”、“技术建模”、“技术系统”，如图3-13：

图3-13 生造的“技术**”

如果为了获利，你有必要思考某“技术”（非核心域）的逻辑，有必要对某“技术”建模，这个所谓的“技术”就变成你的“业务”（核心域）了。有的人只是学习和使用其他人已经充分思考并发布的“技术”，却拔高成思考“技术逻辑”和做“技术建模”。

对ABCD工作流无知的开发人员（伪创新的常客）往往会有自己在研究“技术逻辑”的错觉。他唯一掌握和面对就是D工作流的环境，所以他是面对着D工作流的环境凭感觉脑补ABC工作流的知识（参见第1章），就容易误以为自己思考的是“技术逻辑”。

如果思考的是“后端（这个词不严谨）技术”，他可能还会意识到是在思考“业务逻辑”，如果思考的是“前端（这个词也不严谨）技术”，产生“技术逻辑”错觉的概率就会高很多。其实界面的响应、跳转等背后的逻辑还是和特定系统、特定领域相关，仍然属于核心域逻辑，可以建模为系统的状态机（协议状态机），用不同的“前端技术”实现。

3.2.4 识别业务执行者和业务用例

3.2.4.1 步骤A-2-1-1 识别业务执行者

以某组织为研究对象，在组织之外和组织交互的其他组织就是该组织的执行者。因为研究对象是一个组织，所以叫业务执行者。

例如，以一家商业银行“汉东银行”为研究对象，它的业务执行者如图3-14所示。

图3-14 业务执行者

图3-14中，研究的组织为具体的组织“汉东银行”。由于前面的建模步骤“定位目标组织”确实已经定位了具体的目标组织，因此，建模人员在这一步写上类似“汉东银行”这样的具体组织，是容易做到也很常见的。

但是，图3-14中，3个外部组织（业务执行者）都表达成具体的组织，包括具体个人组织“马宝国”和具体机构“大风厂”、“中国人民银行汉东分行”，这个就不太容易做到。建模人员可能更喜欢表达如图3-15：

图3-15 业务执行者-方案2

在图3-15中，“马宝国”被替换成“汉东市民”，“大风厂”被替换成“汉东企业”，相当于用组织规格代替了组织。“中国人民银行汉东分行”没有变化。

建模人员的想法可能是这样的：

汉东银行不止要为“马宝国”服务，还要为其他汉东市民服务，或者说，市民一端的多重性为“多”。企业多重性也为“多”。这两者都用组织规格代替，以覆盖全体市民和企业。而“中国人民银行汉东分行”是特定的，保持原样。

在认识尚不明确时，暂时表达成图3-15是可以的，但不能以害怕覆盖不全为理由。在业务建模和需求工作流，思考应该倾向于具体，这也是第2章思考愿景时所做的。

如果不是拍脑袋得到“马宝国”，而是经过了定位的思考，那么“马宝国”肯定比“汉东市民”有价值，毕竟它凝结了更多的思考。

如果你害怕“其他市民不管了吗”，那就需要复习第2章。事实上，按照这个思路，“汉东市民”格局都小了。难道全国人民、全世界人民不管了吗？如果全国或全世界的人（在政策框架内）都蜂拥到汉东银行来办业务，汉东银行的负责人估计都要乐开花了。那就应该改成图3-16：

图3-16 业务执行者-方案3

归纳以上的讨论，我们可以把图3-14作为建模的目标。如果暂时无法达到，退到图3-15、图3-16也是可以的。

如果不是在真实项目中建模，而是讨论概念，实际上更多是表达成图3-17。图3-17中，全部使用组织规格。本章前面部分的业务用例图就是这样表示的，本章后面部分的业务用例图大多数也会使用这样的表示。

图3-17 业务执行者-方案4

3.2.4.1 步骤A-2-1-2 识别业务用例

组织为其执行者提供的价值就是组织的用例，即业务用例。

以图3-17的“商业银行”为例，它为“储户”提供的价值有“存款”、“取款”、“转账”，这些可以看作“商业银行”为“储户”提供的用例，表达如图3-18。

图3-18 商业银行的用例

（“存款”、“取款”这两个价值使用频率越来越少了）

业务用例代表组织的价值，这个价值是很难变化的。如果穿越回一百年前，图3-18并没有变化，一直在变化的是业务用例的实现——业务流程。一百年前，银行要实现“储户→转账”的用例，需要许多人脑系统（业务工人）一起协作，现在则变成了少数人脑系统（业务工人）和许多非人信息系统（业务实体）之间的协作，甚至变成全部是非人信息系统（业务实体）之间的协作，如图3-19。