我想问的是，在哪里发出一个货物移动事件？因为入库和出库事件已经被设计为实体，那么是在实体这个记录被创建的时候吗？如果是这样，恐怕已经与事实不符合了，因为事实可能是：入库这个事件不会被“创建”，只能是被“触发”，当然，如果把“创建”等同于“触发”也可以，不过有这样一个隐式的等同规则在里面，不那么直观。

[该贴被admin于2012-09-03 09:45修改过]

我个人认为出库或入库不是一个事件是一个过程, 其实体是出库单或入库单,当出库单或入库单完成时,触发出一个货物移动事件
[该贴被clonalman于2012-09-03 10:53修改过]

不好意思,我插一句.

"入"库, "入" 是动作, 库 是目的方,是涉众. 库 是否可看为领域对象.

库的"入" 的结果 体现为 入库单.

"体现" 即为库对外界 "喊出"某object(例如事件), 外界与之约定的体现为"入库单".

论坛内的计时提示, 是从1-->7 看上去有点别扭, 要是从7-->1 降序就好多了.
[该贴被donglangjohn于2012-09-03 11:00修改过]

建模不是从咬文嚼字上来提炼的,应该看到问题的本质,入库可能要做交接、验收、上架你要提炼出这些不同动作本质上是什么？就是货物从一个位置搬到另一个位置，在不同位置做不同的作业。。（这样抽象才能应付作业流程变更带来的变化）

入库单只是一个凭证，说明货物已经从一个位置(库存外)移动到另一个位置（库存内）。。。

[该贴被clonalman于2012-09-03 11:19修改过]

我上面拿"入库"来阐述,只是想具体化,确实咬文嚼字了. 想表达的和clonalman意思应该差不多吧.

确实, 入库单是表明某货物从一个位置被移动到另一个位置.

呵呵，其实这时我们要搞清楚什么是入库？是有了入库单叫入库，还是货物移动进入了仓库边界内叫入库？

如果货物上面有条码，仓库门口有自动扫描仪，货物移动进入仓库门口时，自动扫描后传入电脑，这是不是也算是入库呢？

所以，出 入 库的核心不是库这个领域模型，而是货物移动这个关键事件，如果这个事件被传入我们的系统，应该也认为是入库，定义为发生入库事件，然后进行事件记录和状态记录。

门口加个自动扫描仪，只是收货凭单或入库凭单输入更方便一点，真正要表明已经入库还必须等到入库流程作业完毕以后，商品库存数量才会异动

比如，入库单可能还会出现入库审批的情况,货物可能已经才仓库内单,还不能用,入库单还没审批确认!!!

这个业务流程过程可能会随着各种业务模式而出现一定的差异，如果模型能含盖得越多系统也就也灵活

货物的条码,应该是用来标识某货物.
自动扫描仪是用来加快速度,便于人工成本的降低.
扫描后传入电脑,可算入库,也可不算入库. 需要看是否还有后续的业务动作.

上面所提到的,基本上都是依据业务规则而添加上的,是附加在领域对象之上的.

入库---个人感觉是 目标物 "被核准(经过复杂的业务检查后)" 进入 系统边界内某个地方(例如"目的地").

banq说道"货物移动这个关键事件 被传入系统 可以定义为入库事件".

既然是"事件", 也就是说"动作"已经完成了.
此时"进行事件记录和状态记录",感觉有点"亡羊补牢"的味道.

如有不敬之处,还望谅解.

这是有可能的，那么这时入库事件就变成触发入库流程了，流程是由事件触发，但是只有事件还不够，还必须使用状态来表达，这也是我之前谈到的状态记录，状态可以记录为：已扫描未核准入库和已扫描已核准入库等的，根据流程的不同环节对应不同的状态。至于事件记录是为了日后进行事件追溯Event Sourcing，包括事件回放等等。

相关主题：
危险的DDD聚合根

业务模型统一描述

[该贴被banq于2012-09-08 15:50修改过]

我觉得，这里的动作，指的是对象的方法，它的责任是对象的能力
事件是，这些能力实施时，如果会产生扩散性后果的 传输载体

如果说，事件指的是对象的动作，对象的方法，那么消息，是传输载体

但无论如何，只要是指代对象的方法，不管是动作还是事件，都肩负对象能力的职责

至于对象的能力是动态的绑定，还是静态的写在类里面，或者使用继承/组合等，它表达了在技术层面，模型的扩展的易便性，总之模型扩展时需要重构
然而，重构要再次做的是：沉淀领域核心，领域的核心不在于是动态绑定对象能力，还是静态绑定对象能力，而在于是否表述出当前领域的差异性特征
而这个差异性特征是通过4个方面展现的，对象的方法能力/方法实施的条件/方法实施的结果/对象通信形式，这里的对象可以是实体名词，可以是服务动词

由于对象方法所承担的能力太复杂，以至于不得不运用策略模式/规格模式/监听者模式等，将方法中的静态的算法分解出来：使用更多的策略对象。将方法中动态的对象调用也分解出来，使用各种各样的通信方式
但这些策略对象分解和通信方式改变，也不能说明领域核心，但除非，分解和改变的结果是表达当前领域差异性的特点，否则只是技术层面地改变

我觉得ddd模型，表达了动词，也表达了名词，动词就是对象方法，名词就是对象方法所能实施的条件和结果
对象的方法，从货运图看，他应该是没有全写上，一些主要说明当前问题的方法还是写了。比如在泳道图上，itinerary被set进cargo，说明了cargo是有setItinerary()方法的,这也表示了货物有一个被计划线路的能力，但这个能力太复杂，他使用一个服务去完成
而即便将这个服务动态的绑定到cargo身上，变成cargo的能力，或者用消息触发完成，这都不能改变这个模型图对货运领域的本质认识，以及它的分解对象的结论

此外，比如说，游戏中桥梁被炸断，表达了2个动作能力：桥梁的被动动作能力：毁坏，和坦克的主动动作能力，射击
这里被动动作，好像桥梁有一个set毁坏(参数)的方法，这里的参数，是毁坏的规格级别，桥梁通过这个方法，接收这个参数后，表达开裂还是断裂。这个参数的毁坏规格级别，肯定是由一个服务提前计算出来的，它肯定还要监听，桥梁被什么武器击中了多少次，才能计算毁坏规格，如何监听，肯定是绑定在桥梁上的set被击中()方法上的
同样的可以，好像桥梁有一个set毁坏(参数)的方法，但是是私有方法，桥梁是通过set被击中()方法内部计算，并产生毁坏规格，自己随时发布给自己的私有方法set毁坏(参数)，来完成被动动作
而坦克的主动动作，当得到攻击请求时，它的射击的频率/射程/威力，是已经存在的规格，它根据这个规格，不停的反复掉用自己的射击()方法，肯定的，有一个服务会监听坦克的射击方法，然后计算出被击中的物体，以及毁坏规格，分发给被击中物的被动方法：set毁坏(毁坏规格的级别)
同样的可以，坦克不停的掉用自己的射击()方法，并且延伸调用自己的一个私有方法：计算攻击范围(),获得被击中物，然后主动调用被击中的被动方法set被击中(),可以传参为：火力级别
在当前，似乎应该是消息机制适合领域模型，也表达了领域的差异性。这导致了和非消息机制模型的差别，当前这种差别是核心的差别。即便是如此，非消息机制的领域模型，还是表达了：对象的方法能力/方法实施的条件/方法实施的结果，这3者所产生的，对象应当具备的方法本身，以及算法/规格等其他对象。但是对象间的调用模式没有表达出来。但如果确认是消息机制为领域的核心部分，那么在建模时就可以在领域图上表达出来？
此外，如果当消息机制成为了语言的自身规格，我们是否依然要考虑这是不是领域核心，才使用消息机制，而非什么都使用？

计算物体击中与否，不应该由坦克自己去计算，否则系统就没有什么弹性了，坦克现在炸的固定的桥梁，以后要是再加入移动的敌方坦克，势必需要修改计算方法；
坦克只管射击，报告自己坐标、角度、火力等参数即可，哪些物体被击与否，损毁情况怎样，由另外相关的订阅服务去处理，综合坦克的火力，击中部位，被击中物体的耐受情况，所以坦克对象不应该直接调用被击中的对象（一发炮弹打中多个目标等?)

(现实情况也是这样的,只有被击中后才能叫被击中物,被击中前都叫"锁定",坦克能计算的只是锁定物,而只有锁定物就谈不上什么损毁了,锁定即损毁是武器系统设计的终极目标啊,呵呵)

消息机制是不是应该是领域的一部分？最好分开消息与消息传递来看问题，还是以坦克射击游戏为例：
坦克射击游戏，坦克只需要进行“射击”，自己的坐标，角度和相关的射击参数封装为一个事件这是领域对象，计算哪些物体的被击中，毁坏程度如何，这是桥梁损毁服务或坦克损毁服务（坦克打坦克）。从事件出发到找到相应的服务方法，这是架构层面的问题，事件的创建与事件订阅服务方法的执行这是业务层面的。
事件对象是属于领域的，事件传递是属于架构的，而不是笼统的说消息机制是否是领域核心。。。

[该贴被clonalman于2012-09-26 09:28修改过]

@banq，我的这个帖子为什么被MASKED，多年没搞DDD了，都忘了写了些什么，回来重新学习一下！！