Domain Model 探索

我怎么看这些ACTs就象一个一个过程（只不过加了点回调），那算什么面向对象啊

这个行为不是有业务主体来完成阿，为什么要把它拿出来？看见了一堆数据和很贫血的方法，然后去要这个ａｃｔ再去操作它？　openService -->openAct->step1,step2,step3...?为什么不是openSercie openMehtod (1,2,3)? 实在看出去ａｃｔ的必要！one method one class　是为了什么？完全是过程化的思想

你说的没错。Act之所以是一个个过程是因为这样一个事实，
各种业务本来就是一个个过程。
Command模式本来就是如此，都只有一个Run方法。
建议去看看Bob大叔的《敏捷软件开发》中的有关Command的
相关阐述。

Command模式是不错，问题是为什么要用，在什么场合下用，我承认业务是一个过程：开户；它描述的对象是“户“这个名词，他有自己的属性　由开户这个动作，我为什么不能操作自己的属性去做事情的，每动一下非得请个ａｃｔ大叔来做？累不累阿？

我晕，Command模式被用来帮这种事了，这不是绕了个大圈做过程，哪有面象对象的好处啊，那还不如直接用一个个过程来得直观，比如AccountHelper.xxx。
举个例子：一个系统有很多种类Order对象，以Order为基类，Order类有一个确认定单动作Order.confirm()。不同子类的订单会执行不同的动作，比如是供应商Order就会发直接生成发货单对象及xxx，是个人用户Order就会yyy等等。按你的方法用Act，是不是要在act中来一堆if来判是什么Order再用作什么处理？还是有一堆Act，比如供应商OrderACT，个人用户OrderACT等等。把而用对象法就可以在查询得到一堆Order后（Hibernate不是可以多态查询吗），直接order.comfirm()就ok了，具体动作由order自已处理，这是多态的好处，比用回调好多了吧。

如果子类中的order.confirm()，需要知道当前的业务类别或当前正在执行该项操作的员工。
你如何得到？

Act的主要目的是提供当前业务运行的上下文。同时完成操作多个业务对象的任务，因为该
操作需要跨越多个对象，这样该方法放入那个对象都不合适。

这看程序需要啊，设计业务类和设计别的应用程序的类（比如文本编辑器）没什么不同啊，也可以在类上应用多态继承策略等，而不是做很多act。当前业务类别不是当前类嘛，操作的员工么要不是有个全局的当前操作者（放在session或是一个类的TheadLocal中），要不就成一个参数传入confirm。

同样一个存钱Act我可以存定期，也可以存活期，两种业务类别。
按照你的说法。不是要弄两个类？


你设计的Session中会包含getEmployee()这样的方法吗？
这样你的Session就不得不同业务层中的Party关联了。


前面讨论Facade时已经讨论过，这种做法不可行。

Act在于封装业务活动, 这个概念很重要，
通过act之间的关系，就构成了业务活动骨架。

但我觉得 只要把act理解成为一种 概念原型（Archetype）就可以了。没有必要做成Interface
或基类之类， 继承的耦合性太高了，实际也不方便。

建议看看color Uml 第1章，可能应该会有收获。