DDD领域驱动设计批评文集做强化自测题获得“软件方法建模师”称号《软件方法》各章合集一样的月光一样的照着新店溪。《一样的月光》词吴念真、罗大佑曲李寿全唱苏芮19823.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 业务执行者-方案43.2.4.1 步骤A-2-1-2 识别业务用例组织为其执行者提供的价值就是组织的用例即业务用例。以图3-17的“商业银行”为例它为“储户”提供的价值有“存款”、“取款”、“转账”这些可以看作“商业银行”为“储户”提供的用例表达如图3-18。图3-18 商业银行的用例“存款”、“取款”这两个价值使用频率越来越少了业务用例代表组织的价值这个价值是很难变化的。如果穿越回一百年前图3-18并没有变化一直在变化的是业务用例的实现——业务流程。一百年前银行要实现“储户→转账”的用例需要许多人脑系统业务工人一起协作现在则变成了少数人脑系统业务工人和许多非人信息系统业务实体之间的协作甚至变成全部是非人信息系统业务实体之间的协作如图3-19。图3-19 用例没变实现用例的零件变了我们把业务流程看作业务用例的实现将其组织在业务用例的下面。组织内部之所以有业务流程是因为要实现业务用例。组织里发生的一切都是为了给业务执行者提供价值。这样的思路对改进业务流程有非常大的帮助先归纳出组织对外提供什么价值再思考如何更好地优化组织流程和更换组织零件来实现这些价值如图3-20所示。图3-20 从价值出发重新构造业务流程