大家好，我是飘渺。
前几天在做架构评审时发现一个现象：不少架构师在做业务建模时都将业务用例画错了，要么画的粒度很细，要么完全是将业务用例当成了系统用例来画。
归根结底，其实是没理解业务建模的本质，没有抓住业务用例的精髓。而要理解业务用例的精髓，咱们得先知道什么是组织，理解了组织，业务建模的核心我们就掌握了一半。
组织
业务建模的目的是从 组织 的角度来定位系统应该提供的价值。
组织开发系统的目的一般是为了优化业务流程，使得业务运转的更加高效、经济。而我们研究组织用例是因为我们想要把系统的价值和组织的价值挂上钩，给组织一个购买（开发）系统的理由。
很多时候我们把自己开发的系统想的太重了，感觉没有我们开发的系统，组织就玩不转了。其实，我们那牛X哄哄的系统也只是组织的一个零件，和组织厕所里的马桶，清洁的阿姨没有本质区别。
为什么需求经常 “容易变化” ？ 根源之一是它们的来路不正，一开始的时候是拍脑袋得来的，没有把系统当作一个零件放在组织中来看，得到的系统当然和组织的其他零件格格不入，系统上线磨合后发现问题，自然要改。
“需求变化剧烈”只是一个假象，许多需求的变化是假的变化，真正的需求并没有变，只不过开发人员一开始捕获的需求是假的。如果能正确运用业务建模技能，大多数假的需求变化会消于无形。遗憾的是，不少开发团队在改进的时候给自己开错了药方，以为应该通过提升设计的弹性来应变。
设计是应对真正需求变化的手段，假的需求变化应该通过改进业务建模来应对。
如果东西拿到客户面前，客户说“好呀，正是我想要的！”，过了半年，客户又说“形势变了，这个东西要改一下。”这是需求变了。如果东西拿到客户面前，客户说“这不是我想要的！”，这时硬要说“需求变了”，脸皮有点厚了。
业务建模既然是研究组织，那么研究哪个组织呢？
最佳的研究范围就是项目愿景波及的、需要改进的组织，它可能是一个公司、一个部门、一间办公室、一个家庭、一群人。
有个简单的办法可以帮助我们确定需要研究的组织：本次开发系统上线后负责运营的单位，可以选定为我们研究的组织。
业务用例
了解了组织的概念后我们再来看业务用例的定义：业务用例是指 业务执行者 希望通过和 组织 交互达到的，而且 组织 能提供的价值。
那何谓 业务执行者？
业务执行者
业务执行者的定义是：在组织之外和组织交互的人群或组织，也可以理解成使用组织所提供的业务的人或单位。
以一家商业银行（组织）为研究对象，谁在外面和它打交道？储户来存钱，企业来贷款，人民银行要对它作监管…。这些就是该商业银行的执行者。
业务执行者的图标是一个小人，头上有一道斜杠，这个带斜杠的小人实际上是一个执行者的构造型<<Business Actor>>的图形表示，如果您使用的UML工具没有这个图形，可以用执行者的小人图标加上文本构造型<<Business Actor>>取代，或者不加构造型也无所谓，因为系统边界框已经表明了研究对象是一个组织，它的执行者自然是业务执行者。
业务工人和业务实体
在寻找业务执行者时，有时会和组织内的人混淆，例如银行里面的营业员。营业员在组织里面，不是业务执行者，我们称其为业务工人（Business Worker），有时候也戏称为人肉系统。
业务执行者和业务工人的区别是：一个在组织外面，一个在组织里面，一个是组织不可替换的，一个是组织可以替换的零件。
业务工人可能会被新的业务工人替换，但更多的可能是被新的业务实体（Business Entity） 替换。业务实体就是组织中的非人系统，例如银行的取款机、点钞机、营业系统。
以一个餐厅作为研究对象，顾客在外面和它打交道，属于业务执行者；领位员，点餐员，厨师等组织内的 “人肉系统” 属于业务工人；开发的餐厅管理系统属于 业务实体。
餐厅业务对象
业务工人、业务实体的图标上也需要带一道斜杠，或者通过<<Business Worker>>和<<Business Entity>>文本构造型取代。当然，如果你选择的UML工具没有这些图形也没关系，只要系统边界框确定了组织，其他几个角色就很明显了。
很多时候开发系统的目的是想通过新的业务实体来优化某些业务流程，提高业务工人的工作效率。拿上面的点餐系统为例，在未开发点餐系统之前，客人进入餐厅，点餐员需要带着菜单跑到顾客边上帮其点菜，开发系统后顾客只需要通过手机自己点餐，除非有特殊情况才需要点餐员帮助。
这时候点餐员变得轻松了，不过遗憾的是，组织也不再需要那么多点餐员了。
业务用例图
搞清楚了上面几个概念以后，我们回过头再看看业务用例的定义。业务用例是指 业务执行者 希望通过和 组织 交互达到的，而且 组织 能提供的价值。
以上面提到的商业银行为例，我们可以这样思考，储户到银行的目的是什么？可能是存款、取款、转账，得到银行针对储户的用例如下：
再比如以餐厅为例，顾客到餐厅的目的主要是点餐，用餐，结账，所以餐厅对于顾客的业务用例如下：
业务工人和业务实体不在业务用例图中出现，因为它们不是组织的价值，而是成本。
业务用例 vs 系统用例
回到开头的那个问题，很多人在画业务用例图的时候经常把业务用例画成了系统用例，两者之间的区别其实很明显，主要体现在两个方面：
（1）属于不同阶段的产物
业务用例是业务分析阶段的产物，理论上是由专门的业务分析师完成；系统用例是需求分析阶段的产物，理论上是由专门的需求/系统分析师完成
只不过在很多企业，这些都是需要由架构师来完成的。
（2）考察的对象不一样
上面已经讲过业务用例是描述组织对外提供的能力，而系统用例是描述系统对外提供的能力。
系统用例是业务用例相应流程中对系统的一个操作。
总结
业务用例是组织的、而不是组织内某个系统的用例。业务用例不是思考系统提供什么“功能”，而是思考组织购买了这个系统，对组织本来就有的哪些“功能”会带来一点点帮助。
一个组织，甚至组织的一条流程都涉及许许多多的系统。在开发不同的系统时，研究业务用例和业务流程，发现得到的结果和开发另一个系统时的研究结果差不多，这是很正常的。开发人员不必因此感到惊慌，更不要因为“业务用例太少”、“业务用例太简单了”不自觉地改变研究对象，把待开发系统的用例搬上来。
