DDD领域驱动设计批评文集>>
《软件方法》强化自测题集>>
《软件方法》各章合集>>
Alan 2022-9-5 9:36
这个不用也可以 ，系统实例属于某个系统，某个实例上的责任，与哪个 源 无关。
UMLChina潘加宇
这个要的。系统有什么责任，这个才是本质的，你再仔细想想看
就是类图和序列图的关系。一定要砍的话，只能砍系统和系统实例之间的关联。
Alan 2022-9-5 9:53
是要的，只是说可以推算出来
UMLChina潘加宇
推算是从本质推算现象。系统-责任不需要依赖于系统实例-消息，反之则不然。
一个货车有四个轮子，两小前轮，两后大轮
可以看这个。轮子的大小只依赖于轮子的属性，轮子的前后还要依赖车的结构约束。想想哪个更本质。
类似的还有，左拐弯，右拐弯，还是大拐弯，小拐弯
Alan 2022-9-7 9:46
在发糕的系统里，一个A系统的所有系统实例 的消息.责任 数量总和， 是不是与 A系统的责任 数量 相等呢？
UMLChina潘加宇
这个“所有实例”的数量可是无穷大了。
应该说，去掉重复元组之后，得到的结果是责任集合的子集。
******
这个问题问的实际上就是:
序列图上的消息是否覆盖了类的所有操作？
如果所有可能的场景都列出来，会的，否则，可能有一些操作很久很久以来都没有被用到。
也可以想想我们写过的所有代码(相当于“序列图上的消息”，string类有那么多方法，我们的代码中用到了其中多少个？
******
不过，从你问的几个问题来看，你的问题并不在这里。
系统首先维护的应该是没有任何冗余的本质模型，相同的信息在逻辑上只存在于一个地方。
虽然从各种“流水大数据”（条件是维护的数据全面的，像上面说的“有可能的场景都列出来”）来推算本质的模型系是可能的，但这个推算的逻辑也不是从天上掉下来的，也是先要理清楚本质的模型是什么，以及各种流水和本质模型的关系。
就像很多年前，我们面对各种各样充满冗余信息的纸质报表，对它们建模，找到本质的模型，这个过程很辛苦！但我们这样做就是要找到背后的本质规律，然后不用受二遍苦重复思考，需要报表时通过规律演算从本质模型得到报表。
就像科学研究一样，背后的物理规律没搞清楚时，可能要大量做实验，研究大量实验数据，拟合曲线等等。一旦找到其中规律，就没有必要从之前做试验得到的已有巨量数据来推测新数据了，我们只需记住探索出来的物理公式即可。
更何况，不是所有的系统都会保存“流水”。就像之前我写的那篇状态机文章中说的：
*有事件发生，未必需要记录事件（有A未必有B）电梯每天上上下下，不知发生多少次“召唤”事件，但是目前的电梯不会记录“召唤”事件的细节——谁召唤的、什么时候召唤的……，当然，也许有一天，电梯有了足够的计算和存储资源，会记录这一切。不记录事件，不代表事件没发生，更不代表事件没有产生效果。
******
现在那些鼓吹“事件溯源”的，以为逻辑是从天上掉下来的呢？
但凡认真学过关系代数而且成绩过关，就会对这些东西留个心眼，但现在很多开发人员，连这些基本的要求都达不到。
[19:30上课]11月7-11月11日晚剔除伪创新的领域驱动设计-网络公开课
[19:30上课]11月14-18晚软件需求设计方法学全程实例剖析网课
[新增架构师专用集锦AD-001]28套UML EA和StarUML的建模示范视频-全程字幕（20221006更新）
《软件方法》书中自测题-题目全文 分卷自测（1-8章）16套111题
《软件方法》强化自测题集110题
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]
如何选择UMLChina服务
作者微信：umlchina2
