DDD领域驱动设计批评文集做强化自测题获得“软件方法建模师”称号《软件方法》各章合集4.1 建模步骤A-4 组织的现状流程4.1.2 业务序列图有了业务工人和业务实体我们可以认为组织的用例业务用例是由组织内的业务工人和业务实体协作完成的。协作的流程如果用UML序列图来表示就是业务序列图。图4-7展示了一张业务序列图图4-7 业务序列图主要元素4.1.2.1 消息的含义序列图最重要的要点是消息的含义。A指向B的消息代表“A请求B做某事”或者“A调用B做某事的服务”“做某事”是B的一个责任。图4-7中指向财务主管的消息“审批报销单”映射了财务主管的“审批报销单”责任。注意消息箭头已经有请求的意思消息名称中不用画蛇添足加上“请求”二字。当然如果“请求*****”本身就是该对象的责任那么消息名称里有“请求*****”是正常的。这样的现象常出现在很多扮演中介或网关、代理、门面角色的系统中。如图4-8AI大模型统一路由的责任确实就只是“请求大模型*****”并不做后面的具体事情。图4-8 消息责任里有“请求*****”的例子在序列图中数据流仅仅作为消息的输入或输出参数存在例如图4-7中的“报销单”。如果不了解这一点就容易把消息的方向当成数据流动的方向不但消息名称没写对还会出现成对的消息如图4-9所示。图4-9 错把消息当成数据流4.1.2.2 生命线头部的实例是系统业务序列图表达组织内各个系统之间的交互。出现在业务序列图生命线头部的实例其合适的颗粒大小就是系统包括人脑系统业务工人和非人系统业务实体比系统大或者比系统小都是不合适的。★参考第2章的图2-7生命线头部的文本冒号左侧对应“系统”实例的“名称”属性值可留空冒号右侧的文本例如图4-7的“财务主管”、“SCS”对应“系统规格”的“名称”属性值。如果建模人员不把“颗粒大小是系统”这一点时刻记在心中打哪指哪抽象级别随着兴之所至而跳跃就会让业务序列图混入不该有的内容。1错例生命线上出现系统的部件图4-10的业务序列图中CRM系统的一个部件“客户表”露了出来但目前的抽象级别并不关心CRM系统中是不是使用关系数据库保存数据以及数据库中是不是有一个表叫“客户”。图4-10 系统的部件露出来了出现这样的问题原因往往还是前文所说的建模人员的“灵机一动”。因为缺乏严谨的方法学指导突然想到什么就视作珍宝害怕忘记了于是迫不及待地堆砌在图中。这样的错误往往表现为“随意”建模人员能“灵机一动”想到的就拼命炫耀“灵感”没顾及的选择性忽略。图4-10中如果真的要考虑系统部件这个抽象级别“分配销售专员”操作也会影响一些表怎么不画出来“销售支持”也有部件当他使用“CRM系统”记录资料时他的大脑负责指挥他的心脏提供能量他的手指负责录入。大脑、心脏、手指怎么没画出来2错例生命线上出现组织图4-11中只有“担保公司”一个业务工人没有其他业务工人或业务实体。图4-11 把“担保公司”整个放进序列图这种情况很有可能是把整个要研究的组织在这里是“担保公司”当作一个业务工人给搬上来了之前画的业务用例图有可能如图4-12图4-12 “担保公司”的用例图和图4-12相比图4-11添加了用例的交互步骤但这是不够的因为它没有剖析出担保公司内部各个人脑系统和非人系统之间的协作。当然图4-11作为一个中间产物存在是可以的。如果建模人员暂时不了解组织内部有哪些人脑系统和非人系统以及各自承担什么责任也可以如图4-11先把整个组织囫囵当成一个系统画出来先理清和外部组织的交互然后在调研过程中进一步细化组织内部。3错例生命线上出现非智能的信息载体如图4-13建模人员把“申请单”的实例放到了生命线上。这样的事情在“申请单”为纸质时更容易发生因为此时申请单的信息放在建模人员看得见摸得着的介质上。这可能也是Jacobson的书以及RUP把类似这些当成业务实体的原因。图4-13 无智能的申请单被错误当成了业务实体申请单只是信息项最多能作为消息参数传递如图4-14所示。图4-14 申请单只能作为消息参数可能有的读者纳闷我怎么记得看过这样的书里面的序列图生命线上出现订单、申请单对象这可以发生在分析工作流。如果在分析工作流用面向对象方法学去构思目标系统的内部结构和行为就会得到订单、申请单等假想的对象。然后我们尽可能把逻辑封装在这些对象对应的类中这样看起来对象就有了生命能承担责任。如果市民使用某个非人信息系统来填申请单该系统的分析序列图可能会如图4-15。在“市民→提交申请”用例中系统会创建“申请单”对象在“科员→审批申请”用例中“申请单”对象可能会收到“审批”的消息。图4-15 分析序列图生命线上可以有申请单对象如果在分析工作流不采用面向对象方法学来构思系统的内部那就没有订单、申请单这些类了但不影响业务建模工作流使用面向对象方法学的产出结果。4.1.2.3 应该出现哪些系统在工作或生活的流程中我们所使用的非人系统远远比我们意识到的多。我们以上面的图4-10为例。“运营部”请求“销售支持”处理客户资料时有可能是通过即时通讯软件例如微信联系的而使用即时通讯软件时可能要用到第三方输入法例如搜狗输入法同理“销售支持”使用“CRM系统”记录客户资料时除了“CRM系统”之外可能要用到浏览器、第三方输入法。★以上只考虑了应用级别的系统还未考虑数据库管理系统、操作系统等基础设施。那么可不可以考虑把图4-10的序列图画成图4-16这样图4-16 把更多的非人信息系统放入序列图一般不会像图4-16这样画理由当然不能仅仅说“直觉”。考虑的出发点应该是领域。此处建模的是销售部的分派客户流程从“销售-客户”领域的视角来看可以判断“搜狗输入法”、“微信”和“销售-客户”领域没有特定关系。一方面如果其他领域的另一个组织也使用“搜狗输入法”和“微信”。当建模人员建模该组织的流程时如果把“搜狗输入法”和“微信”放入序列图应该可以观察到它们所参与的流程片段和图4-16并无区别。另一方面“运营部”使用邮件、QQ、微信、钉钉还是飞书给“销售支持”发资料从“销售-客户”这个领域的视角看没有区别。因此一开始可以不考虑“搜狗输入法”和“微信”等系统。严格来说“搜狗输入法”和“微信”是系统规格。为了兼容读者的阅读习惯在不影响方法学模型严谨性时本书的叙述也采用“系统”的说法。如果只把和“销售-客户”领域特定相关的系统放入序列图经过观察找不到能满足愿景的改进方案或者得到的改进方案难以实现这时可以考虑把另一个相对更“基础”的领域的系统加进来例如“通信”领域的“微信”观察是否可以在这个领域寻找改进点。如果还不行还可以再加入更更“基础”的领域的系统例如“搜狗输入法”。这样的情况虽然稀少但也不是不会发生。还是以图4-10为例如果愿景是“减少客户的平均等待时间”经过仔细观察发现导致时间拖长的罪魁祸首是有部分运营人员、销售支持和销售专员普通话说得不好拼音输入也用得不好喜欢用潮汕话沟通导致各个环节都出现信息传递错误以及需要反复确认最终导致时间拖长。偏偏这些人还是公司老板的亲戚不能替换。此时在流程中引入潮汕话即时翻译机或潮汕话智能输入法也许就可以满足愿景。★此处以潮汕话为例是跟风最近的热门电影《给阿嬷的情书》。读者也可以自行替换为粤语、吴语等其他方言或壮语、藏语等少数民族语言这个时候改进所发生的领域已经和“销售-客户”没有特定关系。发生这样的情况可能意味着之前所定位的目标组织是错误的需要重做第2章的建模。当然即使该组织有可能不是目标组织不妨碍开发组织在有相应能力的情况下顺便帮它做改进或者在没有相应能力的情况下为它推荐更合适的其他开发组织。这里务必要谨慎不要轻易以为自己发现了一片蓝海“潮汕话翻译机或潮汕话输入法”。当初建模人员思考开发组织的能力时如果没有列出这些能力可能意味着建模人员当时认为开发组织的这些能力并没有竞争优势那就不是什么蓝海了。就像一位内分泌科医生遇到一位心慌、手抖、出汗、体重下降的患者。医生一开始以为患者是甲亢打算把他纳入自己写论文的病例。进一步检查却不支持甲亢症状主要与长期焦虑有关。这个病例就不再是内分泌科医生擅长解决的典型病例内分泌科医生可能会推荐患者去看心理医生。4.1.2.4 关于时间在业务流程中可能会有一些行为由时间信号引发。例如每天早上6:30打工人张三手机里的闹钟App响铃每天早上7:30张三出门去上班。为了把业务流程统一表达成系统之间的协作我们把“时间”想象成一个特殊的系统一个上帝造好放在宇宙中的大钟。它向宇宙中的各种人脑系统、非人信息系统发送时间信号。这些系统收到时间信号后如果满足条件会做该做的事情。像上面说的闹钟响和张三出门可以建模成图4-17图4-17 时间引发的行为注意这只是建模时的想象宇宙中并不存在这样一个大钟。闹钟App收到的时间信号实际上来自手机主板上的一个时钟电路张三收到的时间信号实际上来自他肉眼观察手机时钟或其他钟表得到的信息。这样的表达也意味着闹钟App和张三内部存在响应时间信号的逻辑。可以分出一个单独的部件来接收时间信号再由它调用其他部件。这个单独的部件就是“定时器”或“时间接口”。时间是外系统定时器是其他系统中用来和时间系统交互交互是单向的的一个部件二者不能混为一谈。世界上只有一个时间系统但可以有很多个定时器。例如图4-17中闹钟App内部和职员大脑内部可能各自有一个定时器部件。有的书和文章在识别系统用例时说“执行者是定时器”这样的说法混淆了时间和定时器。如果使用面向对象的方法学来分析某个有定时行为的系统系统里的定时器部件就是一个边界类如图4-18所示。图4-18 时间外系统和定时器边界类★也可以不需要单独的“定时器”部件把该部件承担的责任合并到更大的部件中。★从现代物理学的发展我们知道并不存在绝对的、统一的 “时间”每个物体都有自己的时钟。不过对于绝大多数的软件开发来说简单、朴素的时间设定已经够用了。4.1.2.5 合适的责任待续