基于domain object进行OOAD设计

可以尝试一种办法，添加扩展表，主要内容为：

主表：
main_table1{
      id //逻辑主键
      colum2
      colum3
}
main_table2{
      id //逻辑主键
      colum2
      colum3
}

附表：
attr_table{
      table_name //表名
      colum_name //要动态添加的字段名
      attr_name //外键
      attr_value
}

在取主表数据的时候附带到附加表中去取信息，显示给用户。
局限：不过不能完全满足业务变化的要求。附表的信息只能做为扩展中，也就是些附加信息，很难参与具体的业务相结合使用。

真是什么样的需求都有啊

以前上数据库的课的时候听老师说过这个问题，他们也是象楼上说的这样搞的


更多的应该仅仅是多显示几个表里已经有了的字段的问题

[quote="swing]我觉得你这样还不够彻底，想偷懒也没必要这样吧，
要我说，最好有这样的框架，
用户的一个项目，OK，我马上扛笔记本过去给他装上框架系统，
然后用户说.....他的需求，系统根据语音识别，自动生成所有需要的，
然后用户开始试用，也许有段时间，不过最终是反馈，可以书面也可以直接口头对着麦克和系统对话，告诉它哪里缺什么，然后系统自动完善，
最后，系统生成所有需要的文档，XP的团队就生成XP需要的，CMM的就生成CMM的（连评审都给你生成），

最后，跟用户收钱闪人。


语音编程确实有研究的，就是你对着麦克风说语句，系统自动生成程序代码
不过说需求自动生成系统还真不知道有没有研究的，预言将来肯定有
NNNN年前谁知道人能上天啊

让我们共同期待吧

等到那天的时候估计是  一千年以后  我们.......

动不动就有人拿上天，电话啥的这些东西出来

要真这样，天底下就没有不可能的事了

代理模式：
阎宏《JAVA与模式》中写道：
代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用

这一章我也大致看了一下的，没怎么明白LZ的这个问题和代理模式有什么关系
我以为：
不管这个问题由“ProxySubject”或者由“RealSubject”处理，都是要处理的

才接触设计模式，还请各位不吝赐教哦：）　　谢谢！

加一个字段，想不改代码就实现？
那看加什么字段，怎么用。 如果你的字段引入了新的业务含义，而且在你这个系统中要处理，可能么？
当然，如果是简单的CURD，那还是可以做到的。实现一个简单的CURD通用工具，加字段只需通过工具修改下配置文件，也许这样算是满足搂住的需求了。

另外发点牢骚：
我觉得做技术的人，还是少做那种误人子弟的事情为好。更没必要动不动扯一大堆好像很高深的词语堆砌。没意思的。

软件开发过程就是编程语言和开发工具结合使用的过程。
编程语言用来描述，其上有库、框架。
开发工具用来生产，包括软件生命周期中智能的或可视化的辅助工具。
java的现状是重语言而轻工具。
动态语言表现力强，必然会轻工具重语言（目前的单腿跳也不爽）；而静态语言的开发工具仍有很大发展空间。
要实现楼主的需求，对于一门不能指望工具的静态语言，就只好寄希望于框架了。但过于动态 本不是静态语言和关系型数据库的强项。
把开发工作交由客户来做，实在是理想啊。
展望下未来：
我们只提供系统页面的template、theme和一组component（ui component、service component），甚至于只给客户个page designer。 客户在线设计自己想要的页面框架，可在线编辑页面的文字区域，甚至可以达到每客户一perspective的效果。

对于domain的设计，给客户个model designer，让客户设置field，对应的list和form页面同时生效。允许客户在线调整字段的显隐、存取权限、对应component等。
另加一个model relationship designer，叫客户拽来拽去设定model间的关联，同时form页面自动可以编辑关联数据（AJAX），list页面也自动生效。可视化的形式设定search form,data grid等。
提供可视化工作流在线编辑器等工具。

至于涉及到的复杂业务逻辑，提供Action代码编辑器，在客户口述的情况下程序员现场编码在线调试。

注意，上面说的都是系统生产环境下的功能，不是开发环境的单独工具 - 想像成生产环境下的perspective(Eclipse那样的)，点击生产环境页面上的Model Design卡去操作...
至少Zope/Plone有部份类似功能。

展望的结果是，开发过程相对模式化的情况下，程序员不得不去做一些重要的事情。

展望完了，如何实现？

domain object是程序中最稳定的，domain object为什么要修改？ 因为我们要修改系统的功能！

我倒是感觉这个问题和领域没有关系:(
很多系统在设计时考虑到以后需求变化,多加上几个空余列.但是这样的设计,这些数据一般不能参与计算,只能做存储.
还见过一种数据库设计.第一列放上一个参数(int)的,然后在系统部署或者扩展的时候,根据需要填上个数据,然后程序运行中再自动按照这个数据,添上几列.
说的有些模糊,见谅:)

我觉得这个不是领域模型的问题, 更不是 OOAD 的问题, 而是一个 解决方案信息的 "单源性" 问题.

假如加个字段只要改它的持久类代码, 增量编译以后, 数据库表结构可以自动扩展, 其它什么都不用动就正常运行呢?
即使是类与类之间的关系, 假如只需要改相关类上的 引用 或者 引用集合 的定义, 然后数据库表结构都自动调整呢?

Hibernate做不到不代表没人可以做到. TOB就可以.

这篇文章其实无意中点了OOAD的一个死穴。
笔者转向Java Web编程前从事的是传统的Delphi C/S编程。转过来后就觉得J2EE分层太多，每到更改，每层几乎都要涉及，相当麻烦且易出错。在Java Web之余，又涉及了一些ASP、PHP之类的东西，才发觉Web编程也可如此简单，不禁对J2EE产生了很大的疑问：本来可以简单实现的东西，何必搞得那么复杂？
近两年OO水平上涨后才逐渐领会到其中玄机。OO与分层就重要的好处其实业务逻辑的复用！OOAD将数据存储、业务逻辑、表示层分离，就可以适应多种数据存储方式与表示层技术的变化。比方说，你就可以选用多种数据库、XML甚至文本！也可以选择WEB、Rich Client以至于手机、PDA。当存储层与表示层变化时，业务层几乎可以保持不变。原因其实也简单：传统的过程式编程是把他们在一块写，而OO则是分开来写。而天下事总是利弊相当，OOAD的高适应性也就必然为其带来高度的复杂与费时，甚至修改时的麻烦。综上所述，OOP其实是便于扩展而不适于修改。原因简单之极，写在一起的改起来只需改一处，分开写的改起来则要改每一处。
所以是否采用OOAD，要因软件产品的定位而论。如果考虑的是扩展性，业务逻辑相对固定，而存储层、表示层变化多的情况下，OOAD当是不二之选；而存储层、表示层相对固定，业务逻辑变化大的情况下，则应选用过程式编程。如果二者变化程度均衡，则可采用MS骑墙式的方法。笔者这番大胆言论其实并非由理论推导而来，而缘于对当今软件界的实际观察。真正的企业级开发无疑J2EE是主导，这符合第一种情况；而变化迅速的互联网界则以PHP为王，小型桌面系统至今仍以VB、PB、Delphi为佳；而中型系统，无疑以.NET发展得最好。