Domain Model 探索

如果就只是存定期和存活期的区别，那是不用单独开一个类的，成为一个参数就够了，但情况很多时候并不是这么简单的,
比如前面的Order，有未知的Order种类，每种Order的confirm操作又有差别，不会要我每加一种Order就来改相关的所有ACT吧。
关于当前操作者为什么不能传进来，我没细看前面的讨论，没理由不能传进来吧。
对于一个系统，我想只要有业务类和一个很薄的Service层就行了，只需把操作转发给业务类以及实现事务等。比如：
class OrderServiceImpl implements OrderService {
   
    public void confirm(ID orderId) {
        Order order = pm.load(Order.class, orderId);
        order.confirm();
    }
}

定期和活期完全可以用策略模式，和存钱这个动作无关阿，和账户这个抽象对象无关阿，正好是面向对线么
　ａｃｃｏｕｎｔ.save();

具体是哪一种定期和活期；这就看ａｃｃｏｕｎｔ　工厂出来的那种ａｃｃｏｕｎｔ了

呵呵，“以动词为中心”的面向对象？我是不赞成这样来剥离对象的。
面向对象在“以名词为中心”时会比较顺手，也比较容易理解。
不过在碰到涉及多个名词的动作的时候确实会很麻烦。

其本质在于“我们的世界不是面向对象的”

将面向对象调整到“以动词为中心”有点类似于拆东墙补西墙。

不使用接口，就没办法DIP了。


看看我的实现并没有你所说的使用很多if。。
public class OrderAct
{
private Order order;
public override doRun()
{
order.confirm();
}
}
同样道理我也可以使用order的多态。

另外如果在服务层组装业务逻辑，充当控制类。假如同样的业务有不同的应用接口，如：ATM,电话，网上，你如何处理？
再重写一遍？或者调用已经有的？这样你的服务层是相互耦合的。不同的服务，为什么耦合在一起呢？
相反我的实现中只需要给Act添加不同的构造函数就行了。

某个动作足够复杂，就可以建成对象。
看act不顺眼，只要叫成actService.
比如说 “挂失”建成类可以叫 “挂失服务”。
拘泥于以朴素的名词为中心，很难建立起
领域模型。

那你操作多个对象的业务逻辑放在什么名词对象里呢？

不要把事情绝对化了，事实上操作多个平等对象是很少见的，而万一有这种操作的确是可以作一个独立Helper对象来处理，但
绝大部分操作都是以某个对象为中心的，比如Order.confirm，例如要一个操作者Operator对象，那这个Operator可以
作参数传进来，但这个方法是Order.confirm(Operator op)，
而不是Operator.confirm(Order order)或
OrderService.confirm(Order order, Operator op);

这种思想是不对的，仅仅是为了重用的话，信息量越少，重用率肯定越高。one method one class的重用率肯定是最高的。但是不易于管理。

＂ATM,电话，网上＂　作为客户他们　看到的account的样子肯定是不一样的，为什么不让他们自己描述他们希望看到的account的样子那？　最后　atmAccount,telephoneAccount......做出不同的操作，这才叫封装！　而不是
atmAccountOpenService telephonAccountopenService这样的类

呵呵，还是把前面有关Facade的论述看看好吗？

你有没有实践过先？怎么个不易管理？管理什么？



我说的同你理解的根本是两回事