求建模意见及建议

建模现在是对象建模，数据库建模已经是过去时代，现在是OO时代，从分析设计到编程都是围绕对象，数据库只是在部署时进行配置，数据库已经和服务器或操作系统或JDK都变成系统管理员的事情，怎么可能还会上升到软件最高阶段建模呢？

对象建模就是买本Evans DDD书看看，学习UML。对象建模不是每个人学完这些知识就能拿起建模工具就能下手的，就象不是每个人拿起油画笔就能画油画一样，这是一个专业，而且需要有多年项目实践经验。

所以，建模也不需要软件背景，只要有专业领域背景就可以，而且有自己对业务的抽象概况思维总结能力，说白了，非得是某个领域专家，比如企业管理软件建模，他就是管理专家；财务软件建模，他就是财务专家等等。

建模其实不是程序员的事情，充其量，一些老程序员由于做某个软件做了N多年，对业务系统也滚瓜烂熟，这时他可以兼做建模，但是不是说软件知识是建模必须的。

可以说：建模是业务专家做的事情，不是程序员做的。所以，从这点可以看出所谓数据库建模更是扯淡了，让对软件不懂的业务专家先学习数据库，再对自己业务建模，
简直是笑话。

什么是业务专家
http://www.jdon.com/jivejdon/thread/32044.html
[该贴被banq于2007年07月10日 16:53修改过]

首先谢谢banq大哥的回复,有以下几个问题
1数据库建模已经是过去时代?
难道数据库就真的该终结了吗,下载是像banq您所注的"数据库时代的终结"那样不应该存在,但是现在的系统架构为什么还会提出一个持久层的概念呢?

2非得是某个领域专家?建模其实不是程序员的事情?
我们都是一些程序员起家,对于作行业软件我们的业务知识是要在开发的过程当中不断的积累,那我们是不是就不能往这方面走呢,只能一本正经的作开发,并且专家的话只是对行业有资深的经理,但是对软件的理论应该比我们开发人员可能会欠缺点,我觉得建模应该是建模是业务专家和软件开发人员共同的一件事情?

>但是现在的系统架构为什么还会提出一个持久层的概念呢?
数据库是持久层一个具体实现，两者不是同一个概念，保存文件也属于持久层一种手段。正是提出持久层这样一个抽象概念，就将数据库更从架构设计中抹去了，举个例子，本来高层开会时，老是提你的名字，但是后来，不提你的名字，提你部门名字，虽然你还在这个部门，并且做主管，但是你肯定感觉自己个人重要性下降，有些不爽吧。开个玩笑。

>我觉得建模应该是建模是业务专家和软件开发人员共同的一件事情
原来大家是这么认为，但是实践证明，两者很难协调沟通，就象鸡和鸭讲话一样，尽管有UML这个共同语言，但是对于同一个UML符合，两种人员会从自己的观点 ，也就是从两个不同观点去理解。Evans DDD伟大革命之处就在于，他提出建模人员从分析设计全部包揽，因为数据库等具体知识已经从分析设计领域剔除出去，对于建模人员进入设计领域已经没有任何技术障碍。然后开发人员再依赖框架来实现建模人员的分析设计结果，甚至无需开发人员，通过MDSD工具可以直接生成代码。TSS最近介绍了这方面一个工具Sculptor，可生成spring+Hibernate多层架构代码：
http://www.theserverside.com/tt/articles/article.tss?l=ProductivityWithSculptor

你问我未来软件人员的位置在哪里？两个：
1. 依靠面向过程设计那些旧代码苟延残喘。
2. 依靠OO思想，掌握机器不能替代的复杂软件设计编码工作。

软件人员和工人一样，也会遭受来自自动化流水线的挑战，下岗或转岗。这是必然的。

[该贴被banq于2007年07月17日 13:24修改过]