Domain Model 探索

ok。那么我认为我们基本上达成一致了。
从设计和实现的角度来说，我同意你所说的“对象决定行为”。但是对象从哪里来呢？
从业务分析的角度来说，从外部行为入手进行分析，更容易发现隐藏着的对象，在这一点上，我认为partech的思路是非常有意义的（当然我反对他把这个思路进一步带到设计和实现中）

BTW:“出去”是不是“除去”的意思？

对的。

不过我不同意先封好层次再把业务往里面套的分析，可能个人的习惯不同，也可能再和现场的讨论业务的人，他们总喜欢注重于流程的讲解有关。从这个方面讲：从外部行为入手进行分析。方法也很不错

过去的事情就让它过去吧

人因为有了记忆而成就了智慧，然而记忆也能使人烦恼。
环境给人很大的压力，人通常会在梦中重现童年时那些紧张，甚至可怕的场景。
同样，在Domain Model设计中，如果把现实同历史牵扯到一起同样会造成麻烦。
我的意思是注意处理好“表示状态”与“表示事件”的两类对象。
这要看你的设计了，可以有两种方法：
1：对于Customer可以给它一个属性RegisterDate表示开户日期。
2：将RegisterDate放入开户事件中，该事件同Customer关联。
同样的可以处理DeregisterDate销户日期。
对于1方法需要注意的是这种设计的业务对象混合了现实和历史，假如设计
者没有意识到这点的话，就有可能“作噩梦”，呵呵这可不是唬人的。
同Customer有关的操作随着时间是不断发生的，而这些无论如何都不应当去修改Customer对象。
事件的属性不是主体的属性。
也许有人会争辩道：“客户开户日期是不能改变的，而且只有一个，我可以认为是客户的属性”。
这就好比把人的出生日期刻在他的脑门上，呵呵，因为这是他的属性啊！？

将状态对象同事件对象分开，就如同人和他干过的事情是不同的一样，这有助于更好的理解业务。
同时状态对象同事件对象的关联一定不要弄反了，所建立关联一定是事件对象知道状态对象而不是相反。

事件对象同事件对象之间可以相互关联。状态对象之间也一样。

如果你不小心建立了状态对象到事件对象的关联，那你就会理解什么是“噩梦”了，赫赫。

区分两者的规则其实很简单。
前者属性中没有时间，后者属性中会同时间相关。

过去的事情就让它过去吧，要不人一定会烦恼而死。

(待续)

好文，不过

似乎有点绝对。创建一个账户，把开户日作为账户的一个属性也很正常。
至于相应的事件对象作为对事务的跟踪，记录账户变化的过程，重复简历账户的属性也很正常。

呵呵，我是说如果设计者没有意识到这是混合了状态和事件的属性的话。
如果清醒的知道这点，那又另当别论，因为这时会小心的处理同它有关的问题。

不错！
不过讨论到后来，变成了面向对象的语义啦

采用所有action(command) 赖实现业务从某种意义上讲是面向过程的吧，用太多的command 有反模式的味道。我的理解不知道对不对，我的实践不多，可能只是理论派，只想讨论一下

是不是把command做为application logic层呢？

首先澄清下是Act不是Action，Action容易同表示层中的混淆。
Act是控制类的实现，控制类确实是面向过程的，不过你也可以把它持久化。
从Aspect的观点看，Act是实现用户价值的活动聚合，是基于关注点的聚合。

是不是command呢？我看到了run();用在银行业务上是来解偶时间的吗？我不知道银行业务。