一样的月光，一样的照着新店溪。
《一样的月光》；词：吴念真、罗大佑，曲：李寿全，唱：苏芮；1982
3.1 业务用例
3.1.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.1.2 用例的概念
用例（use case）是主体（subject）可以提供而且满足涉众（stakeholder）期望的价值，通过主体和执行者（actor）之间的动作序列达到。
图3-1 用例
当主体是系统时，用例是系统用例，表达系统的价值以及围绕这个价值的系统需求集合。这是用例最常用的场合。
图3-2表达了“网约车平台”这个系统的用例：
图3-2 网约车平台的用例
这个用例会将一些相关的系统需求组织起来，如图3-3：
图3-3 系统用例背后的系统需求
当主体是组织时，用例是业务用例，表达一个组织为其他组织提供的价值。
图3-4表达了医院的用例：
图3-4 医院的用例
同样，一个业务用例隐含了组织的若干流程，如图3-5：
图3-5 业务用例背后的组织流程
图3-4和图3-5中的小人和椭圆带了一道斜杠，这是构造型<>（业务执行者）和<>（业务执行者）的图形表示，意思是“我是某个外部组织”、“我是某个组织的用例”。
如果您使用的建模工具没有这个图形，可以用执行者的小人图标加上文本构造型<>、<>取代，用中文<<业务执行者>>、<<业务用例>>也可以，或者不加构造型也无所谓，因为边界框中的“医院”这个名称已经表明了主体是一个组织，它的执行者、用例自然是业务执行者和业务用例。
3.1.3 “业务”一词的含糊
“业务（business）”这个词在软件开发组织中使用得很频繁。经常可以听到“我是一名业务架构师”、“我们要了解业务”等等话语，但是往往说话的人未必真的理解话语中的“业务”具体指什么。
（1）有时候“业务”的含义是“领域”，更严谨的说法是“核心域”或“问题域”。
例如，一个餐馆系统，订单和菜品的关系属于“业务知识”，折扣的计算规则属于“业务规则”，如图3-6：
图3-6 展示餐饮领域“业务”知识的类图
此时，和“业务”一词相对应的是“技术”。
开发人员假装谦虚“我是做技术的，业务不太懂唉”，就是这个意思。甚至有的开发人员在潜意识里是这样划分的：
我懂且我感兴趣的知识→技术；（我是一名Java程序员，Java编码是技术）
我懂但不感兴趣的知识→业务；（下单、收银、配送我懂一些，但不感兴趣，这些是业务）
我不懂但感兴趣的知识→高科技；（我不懂深度学习，但很感兴趣，哇塞，高科技）
我不懂且不感兴趣的东东→忽悠。（我不懂UML建模，也不感兴趣，妈的，忽悠）
（2）有时候“业务”的含义是“组织”或“组织级别”。
例如，“业务建模”说的是组织的建模，“业务用例”说的是组织为其他组织提供的用例，“业务流程”说的是组织内各个系统之间协作的流程。
图3-7表达了餐馆组织的流程，也就是所谓“业务”流程。
图3-7 餐馆组织的“业务”流程
此时，和“业务”相对应的就是“系统”了。图3-7中，餐馆组织里有许多人脑系统和非人系统。包括前文所说的“业务用例”和“系统用例”，也是这样的对应。
我把一些常用的“业务”用词汇总如下，供读者查阅。不全之处，欢迎读者补充。
| “业务”的含义 | 用词 |
|---|---|
| 组织、组织级别 | 业务建模业务用例业务执行者业务工人业务实体业务流程 |
| 核心域、问题域、领域 | 业务规则业务知识业务人员懂业务 |
| 含义不明，不提倡使用 | 业务架构 |
| 常见于伪创新圈子的错误 | 业务需求业务领域业务用户业务用户领域需求 |
图3-8 “业务”在不同用语中的含义
如果不了解“业务”的这两个含义的区别，就会导致乱用或者第1章提到的砌词。
“业务用例”就是一个常见的乱用。很多人觉得，我在说用例时没有谈到“技术”嘛，所以用例自然就是“业务”的了！于是，“业务用例”顺口而出。
其实这里的“业务”是“组织”的意思。
Scott Millett在“Patterns, Principles, and Practices of Domain-Driven Design”书中，大量使用了“business use case”，如图3-9。
图3-9 摘自“Patterns, Principles, and Practices of Domain-Driven Design”中译本，《领域驱动设计模式、原理与实践》
其实从“应用程序的使用场景”可知，Scott Millett所说的“业务用例”是系统用例。另外，他还使用了“业务用户（business user）”这样的砌词——有“非业务用户”吗？
★我在《DDD领域驱动设计批评》文集有一篇文章，就提到DDD圈子创造的“技术建模”一词。
国内领域驱动设计圈子的书也有类似问题，图3-10摘自张逸《解构领域驱动设计》一书：
图3-10 摘自张逸《解构领域驱动设计》
都讨论分层架构、基础设施了，这里的“业务用例”应该是“系统用例”或“用例”。
国内的领域驱动设计圈子其他类似例子，读者可以自行搜“领域驱动设计 业务用例”、“DDD 业务用例”。
