"结果弄得一层层的封装，弄得一堆类"，这个问题分两方面看：
面向对象的系统因为是执行分派、细化原则，所以会有很多类，这是一件好事，如果别人无法理解，是他们的问题，你可画一些UML类图或顺序图帮助他们理解。

在这种情况下，最好在一级目录下是接口类，这样，接口多一些，要比类多一些更好，说明你已经对系统抽象到一定程序，如果接口少，而普通类很多，我认为OO还没到位，面向接口编程不是一步到位的，如果你的系统做到了面向接口编程，每层封装之间交互都是通过各自的接口进行，那么说明你的系统OO已经到位了。不别在乎别人怎么看。

不要为了模式而模式，重整你的系统，如果发现类关系如果用模式表达更合适，就重整到模式，因为模式的好处还有助于别人理解。

当然，面向接口编程规模大到一定程度，可以使用一些框架来管理你的结构，如PicoContainer和Spring都是不错的选择。这样，更有助于别人理解了。我们以前帖子讨论了，PicoContainer和Spring这样的框架其实替代了一些模式，如Singleton模式等，所以，从设计来讲，这些都是一脉相承的，从模式到框架，都是为了更好地实现封装、细化和抽象，实现面向接口编程OO系统的最高目标。

其实还有很多迷茫的东西，我确实经常被称为过分设计。
不过现在我仍然觉得我不能好好的做到设计。
泛泛的学习了UML，也泛泛的学习了设计模式。最近也开始理解对接口编程。这些我都觉得还不错，现在都还没有学习透彻，不能运用一心。

但是框架这个东西，也不知道是不是误解，什么框架都还是利于某种平台上，模式更多的是一种方法和处理问题的思想的总结，而框架仿佛是依赖某种平台的实现，如果平台跨了，框架何从谈起，学习框架不属于一种浪费时间，将自己绑与某种平台上的赌博么，特别是java，框架满天飞，我们解决具体问题的时候他们究竟能带来多大的作用呢！

不过可能还是我自己没有理解吧，请教各位大虾

面向对象的编程和设计经过这么多年的考验，已经被证明是一种非常好的设计方法，面向数据库的编程如果真的比oo要好，那pb,foxpro之类的东西还要大行其道呢，不过确实像楼主提的，好多程序虽然用的是面向对象的语言，实际还都是面向数据库的那一套东西，（包括现在在单位维护的电信boss系统），把面向对象的系统得有点都埋没了~
为什么出现面向对象的设计？其实很简单，为了软件能够复用。oo的出现使软件复用由结构提升到了 类 的层次。有了复用，就有了良好的可维护性。这对大型系统来说是非常重要的。如果你面向数据库的思想，一个动作写一个类，类里边些数据库的操作，哪里来的复用？到时候维护起来也会很困难……

不过话说回来，就算是面向数据库的思想又怎么样……软件一样跑，维护是麻烦了点，不过更容易理解，跟客户关系好，修改的话还能多要点工作日，挣钱更容易~~

所以说吗……软件的关键所在不是oo,也不是db,是关系……

赞同这种开发方式。也许是我还没遇到过比较复杂一点的项目吧。我认为用微元素，可以让编码看起来更清晰，明确。在很多时候迭代也很方便。老是用Iterator很不舒服。

请问业务对象如何之来？是基于需求然后设计出所谓的业务数据表，再用OOD的方式将其封装？

我觉得这种方式固然很稳定，这种过程已经沉淀了几年了... 但是再构建系统的时候，是不能忽略域模型的，因为这样会造成一个误区。Banq之前已经提过“Object-Relational Impedance Mismatch”。

因为在初次考虑的时候可能表是OK的，但是要知道需求是变化的。系统重构也是难免的。这时候这种表设计方式就会遇到考验。因为在数据表和对象之间存在着一种抵抗力。这也是ORM和OOA日渐流行的驱动因素之一。我不批评面向数据表，但是他确实应该改变了！