“创新”何太急-评张逸的“业务服务”（一）
张逸发了新文《业务服务的价值在哪里》（https://mp.weixin.qq.com/s/mb3-WHXziNy-KAa0caUlYg），讲述了他的“创新”：业务服务。
评点一、关于业务用例
张逸原文
如果站在整个企业的角度去思考用例的定义，就应以待开发的目标系统为边界，探讨参与者与目标系统之间的行为，从而形成业务用例
*******
“站在整个企业的角度”，怎么就转到了“以待开发的目标系统为边界”？
这个陈述和我之前批评过的“状态和事件本质是相同的”（参见《DDD话语批评之一：评张逸的“状态和事件本质相同”》）类似，连基本的概念都表达不清楚，根本不值得一驳。
奈何，互吹互捧的“圈子文化”威力实在太强，充满着错误的文章可能会流传甚广，我只能耐心地写文章一点点来解释和普及知识。
业务用例是什么
业务用例是组织为其他组织提供的价值。
组织可以是人群、机构，机构可以是企业、政府、非营利组织、家庭……。
*上面张逸说的“站在整个企业的角度”是不严谨的，可以说“站在整个组织的角度”。当然，这是小问题，图2中，Ivar Jacobson也是这样说的。不过，Ivar是1995年说的，现在是2021年。
用例是Ivar Jacobson提出的，本来是用于描述系统的需求。在"The Object Advantage"（1995）中，Ivar Jacobson开始将用例和面向对象思想用于描述业务流程，把业务流程看作是一系列业务对象之间为了完成业务用例而进行的协作，如图2。
RUP（Rational Unified Process）的描述更清晰一些，如图3。
图3中，组织（这里应该是银行）为顾客（人群）提供“现金交易”的价值（业务用例），但顾客没有直接和某个信息系统交互，而是由柜员（Clerk）和贷款专员（Loan Specialist）来使用某个或某些信息系统提供的价值（系统用例，价值小一些）来做到。
张逸文中提到的“参与者和目标系统之间的行为”，实际上是图3的最下面一格，系统用例。
*当然，图3也存在问题。中间一格，Clerk和Account、Loan等直接关联，这是不恰当的，详情可参见我的《答疑：不同的方法对业务实体的定义多少有些差异》一文。
图4是我画的更清晰的图。
对业务用例的误解
很多人对业务用例的误解出在“业务”两个字上，觉得：我在说用例时没有谈到“技术”嘛，所以用例自然就是“业务”的了！
其实这里的“业务”是“组织”的意思。
关于“业务”一词的更详细解读，我在《CTO也糊涂的常用术语：功能模块、业务架构、用户需求、文档、过度设计……》一文中，用了一定的篇幅来叙述。如果您阅读完《CTO也糊涂……》这篇文章，可以试试看下面这句话中有多少乱用的术语。
在设计用户的业务需求分析模型文档时，要注意写清楚业务系统的各个业务架构功能模块。
******
我从2005年开始使用业务用例和业务序列图做业务建模，也指导很多团队做了大量的业务建模工作。通过大量的实践不断调整和加深对业务建模的认识，我认为许多先行者没有考虑过或者考虑不周到的问题，我已经考虑过了。
*之所以写"从2005年开始"，是因为在这之前业务建模的业务流程部分我用的是活动图。
以下资料，如果读者能耐心看完做完，相信您对业务用例的困惑会消失。当然，在此基础上可能会带来新的困惑，那么这些困惑可能对我是有价值的，有时间的话不妨告诉我，共同提高。
*资料一：
我写的《软件方法（上）：业务建模和需求，第2版》第3章：业务建模之业务用例图，并把第3章自测题做到全对。微信读书有此书。
《软件方法》勘误
http://umlchina.com/book/errata2ed.html
https://mp.weixin.qq.com/s/Xj9YoZzuR-4loMXwBubEag
*资料二：
不想看书的，也可以看以下压缩包中的第三个幻灯片。
《软件需求设计方法学全程实例剖析》幻灯片01-09打包下载地址
https://pan.baidu.com/s/1su8FdMqyDQF-tJ1mgcMMYQ，提取码：umlc
同样，把《软件方法（上）：业务建模和需求，第2版》第3章自测题做到全对。
*资料三：
阅读UMLChina答疑记录的“业务建模”部分
http://www.umlchina.com/qa/Index1.html#bm
这是我在2005-2021年的各种答疑精选（目前共990个问题），也可以在该页面按关键词搜“业务用例”。如果还有兴趣，可以继续阅读下面的需求部分（系统用例）。
*资料四：
如果感兴趣，这里还有更难的题：
https://mp.weixin.qq.com/s/GDfIMgdZ8VWWmrNF-axmsw
（待续……）
后续文章：
评点二、关于用例的“客观标准”
……
没有“标准答案”，也不应该期望有什么“标准答案”。
只有推导“最佳答案”的思考方法，而这些思考方法是非常严肃而且客观的，但是思考起来并不容易！
或者可以这样说，给出不用思考的“标准答案”的，基本可以认为是骗子。
……
评点三、关于需求到设计的“转化成本”
……
如果有人不愿意面对这些复杂性，也不愿意学习这些复杂思考方法，反而从中看到机会，“发明”一种一一对应，不用思考的“方法学”，宣称现在的方法太难了，我这里有“成本低”、“一一对应”、“标准客观”的做法，向同样不愿意面对这些复杂性，也不愿意学习这些复杂思考方法的开发人员宣传。这就不应该了。
……
评点四、“不可视”不等于“深入系统内部”
评点五、关于“用户”和“用户需求”
评点六、关于“业务服务规约”
已发表的相关文章：
猴子掰玉米？比较不同版《领域驱动设计》说“不变式”和“聚合”