看了一篇讨论：
http://www.cnblogs.com/yimlin/archive/2006/11/30/578333.html
有些感想：并不是所有的行为都必须属于某个对象，有的行为似乎放在任何一个对象中都不合适，那就单独放在那里好了，没必要非要造出一个对象来，更不能把它硬安在某个对象上。
按照oop的方法，软件的逻辑架构可以分成下面几个层次：
1：基础设施层——这个层次解决的是物理问题，比如database gateway、网络通信、对象容器……这个部分与业务需求关系不大，是系统的物理条件。有很多技术框架帮助我们尽快的把这个层搭起来，比如web server、中间件、ACE。搞软件的公司会在这方面形成自己的技术积累。开始搞一个项目的时候，经常把以前的东西拿来复用，尽快进入后面的工作。
2：business对象——在这个层次上，业务要素出现了，业务领域中的概念在这里实现。比如一个航运公司的系统，这里就应该有航线、航班、座位、乘客、登机牌……这些对象应该拥有与实际业务领域相符的属性、方法。长期在某个业务领域开发的公司，在这方面也应该形成自己的技术积累，形成可以直接复用的对象模型。这个层次上也是有一些现成的产品可以用的，比如SAP、工作流引擎，可以在这些东西的基础上做定制开发。
3：business流程——这个流程不是指程序解决问题的流程，而是用户的商业活动的流程。他体现的是端到端的业务流程。比如：检票员为旅客办理登机牌。business流程的输入参数是business对象，输出参数也是business对象。business对象在这里组合、串接，实现业务流程的自动化。这个层次是在直接实现用户的需求。
4：UI和接口——这个层面调用business流程，将执行的结果交给软件的用户，或者别的系统。
在“3：business流程”这个层次上，并不是每个行为都可以在系统中找到一个归属的对象，这是正常的。没有必要为了oo而oo，一定要给某个行为找到一个对象。尤其是不能把这些行为硬安在某个不相关的business对象上，那样反而会使系统变得混乱，难以理解。business流程的独立存在不会误导任何人。
从一个大的范围上说，这些business流程的所属对象，应该是系统的使用人。不应该花太大的精力，过多的考虑这些行为应该属于哪个实体。