Domain Model 探索

您的理解是？

看来有些人对将业务活动建模成类不适应。:)
那我就多费点口舌，看看这样能否缓解你的不适。

我们在察看自己的储蓄帐户时通常不光会只看余额，
还要看看历史的交易记录。这意味着存款、取款等这些
操作需要持久化。
持久化的信息可能包括发生时间，发生地点，业务类别...
这样你可以把业务活动看作是一个实体类。
怎么样，有没有感觉舒服些？

这是我比较头痛的一个问题，一般情况下放在作为主语的对象里
但是在某些情况下确实需要把动词单独抽出来做实体对象



呵呵，这个问题我是用“事件”这个名词来解决的，注意“事件”是不包含
业务逻辑的

你的“事件”不就是我业务活动Act的持久化吗？
没有业务活动就没有事件。
同样你在说一个事件的时候，难道不是在说一个业务活动吗？
可见你说的事件就是我说的业务活动Act。
一个是运行状态，一个是持久状态。表达的是同样一个概念不同状态。

名词 储蓄帐户（业务类别）： 事件（ 时间 地点 ）
然后看两者之间的关系 事件不会自己触发，总是由被侦听者触发：这里就是 储蓄账户 两者应该以observe模式结合起来，

Class account :{
    Ievent saveEvent = eventFactroy.CreateEvent();;
   Ievnet getTriggeredEvent();{
      ....................
   } 
   open();{
         .......
         saveEvent.trigger(this);;
         accountMapper.save(this);;
    }
}
################
Class saveEvent implent event();{
          trigger();{
               saveEventMapper.save(event);:
          }
}

或者直接
   accountMapper.save(this，event);;

为什么要让event  来控制account呢？ 每以个event一个来控制一组对象？

什么时候该把业务活动建模成类呢？
这里提供一个color uml中的说法：
就我理解，在color uml中把 楼主的"Act"的情况称作
“时刻/间隔”原型（Moment/Interval）,由于业务或
法律原因而必须追踪的（事件或活动）中的时刻和间隔。

也就是说如果关心时间，就有必要把业务活动建模成类。

to frankensteinlin
我们是两个世界的人呢，你说的俺听不懂。我说的你也听不懂。555~~~~~~~~

to tuti
color UML是什么？

我认为这两者除开状态的差别以外，关键还在于业务逻辑处理范围的不同。

我理解你所说的业务活动Act不单要处理该业务活动本身的逻辑（例如时间、状态、地点等），还要控制该业务活动所涉及的其它对象的业务逻辑，例如你所举的例子中的Customer。

而我所说的事件仅控制其本身的逻辑，不包括该业务活动所涉及的其它对象的业务逻辑。从代码上来讲就是该“事件”所对应的类中不会涉及到其它对象

对于你的问题：当在实际应用中碰到“以动词为中心”的业务逻辑，它涉及到多个地位平等的名词对象，将该动词化为任何一个名词对象的方法都会觉得不是很合适。

我也曾经有过同样的困惑，目前也还没有很好的解决办法。
但是我不认为你所提的“以业务活动为中心”是一个比较好的解决办法，在我看来这是从面向对象又倒退到面向过程。

对于你的例子，我的建议是针对此类业务活动引入或找到名词对象。
例如对于存款引入“存款单”，对于取款引入“取款单”
不过这样做的缺点是丧失了“存款”、“取款”这类业务活动一些比较共同的特征……

关于color uml 看这贴。
http://forum.iteye.com/viewtopic.php?t=1407&highlight=

如果可以，一切都是接口，面向服务层的接口，业务对象的接口。是否一个类实现还是多个类实现，只是一个文件管理的问题。