最主要的我还没有看到谁做的那域模型，比我自己用的这套思想好些，当然经过比较后确实感觉有能比自己的思想好，当然我会采纳的。

我觉得OOA需要对问题域的深刻认识，所以还要有subject matter expert的指导，抽象出你的各个对象。当然如果你的业务对象以及它们之间的关系没有那么复杂的话或者以前已经分析过（甚至是legacy system）直接采用的话，可能没有OOA都可以的。一般大型系统还是需要OOA，理顺研究对象以及关系。至于说从数据模型入手，将OO实现甚至OOD依赖于数据模型的做法是非正统做法了（可能在某些情况下仍然可以采纳）。这种bottom up的办法无法适用业务领域的需求千变万化和业务发展变化。而且根据系统的发展来说是先有需求，后有模型，再有实现（包括存储的数据模型）。

建模非常重要性，关系到项目、产品的成败，但是现在的开发效率底下也是影响项目成败的主要原因，在java方面以前没有更好的工具只能用 DW＋eclipse，现在 elinkBSP 的推出，解决的这方面的问题，也是建模和开发沟通的载体，开发人员只作 Codeing 部分，设计人员只作 Designer 部分，设计人员指导开发人员，完成项目开发

不知道banq老大有没有读过domain model design这本书。该书对我启发很大。不进行ooa就进行ood,真的可以吗？
软件的需求如果是用功能列表的方式写的，实现的时候用ood,我想花费的代价比起先建立domain model再写use case 来说要大。
如果用use case来写需求但是没有ooa也就是没有domain model的情况下，use case里的所有涉及到系统反应的时候又该如何来清楚地表达，分析员与设计人员之间的交流又该如何有效地执行。
我相信，只有一份feature list文档，仍然有人能用ood的方式实现出来，只是这个时候，ood也承担了很多ooa的工作，而不是说ooa没有做而已。
技术要有效，要加入软件流程与项目管理，没有ooa就ood,我觉得前期的分析只是在waste time而已。写一个简单的hello world无论有没有ooa都行，写个小的网站只有10来个对象也无所谓，然而当一个系统在增长的时候，没有ooa也就不要再ood了。

Evans DDD是将对象建模推向顶峰，国外2001年就发文认为对象建模是站立在E-R模型也就是数据库模型之上的。

对象建模和E-R Model虽然都是建模，但两种有完全不同：
面向对象建模与数据库建模两种分析设计方法的比较:
http://www.jdon.com/mda/oo_relation.html
[该贴被banq于2007年09月23日 20:29修改过]

感觉好多学科的发展都有些相似。以数学为例，从初等算数几何到高等代数给人的感觉就是这样：好像分析解决问题的方法有了质变，有了同性，之后对于个别问题来说越来越复杂的步骤却成了高级阶段的追求。对于初等的个别的感性认识逐步特例化，神秘化，边缘化，取而代之的是系统的规模的通法。也就是说将来剩余两种职业：1. 建模专家 2. 框架设计师是可能的。前提是基础程序的通法被高度的统一，课本化。