首先两者比较：
我下面是引用的别人的文章，并且感觉有句话很好，不过除了这句话其它的话都不是很好，哈哈：有些人就把问题归结于Java语言本身，睡不着觉怪床歪。
我们知道：一个软件从无到有需要经过如下几个阶段：分析、设计、编程、调试、部署和运行。
编程阶段我们通常使用Java/.NET这样面向对象语言工具，可以带来很多设计上的好处，但是也存在一个奇怪的现象：很多程序员虽然在使用OO语言，但是却在code非OO的代码，最终导致系统性能降低或失败，这个现象在Java语言尤其显得突出，难怪有些人就把问题归结于Java语言本身，睡不着觉怪床歪，又为了面子问题，说自己转向.NET，实际上是在 回避自己的问题和弱点。
那么，这些人的问题和弱点体现在什么地方呢？从上面软件生产过程来看，每个阶段都对前面有所依赖， 在编程阶段出问题，追根溯源，问题无疑出在分析和设计阶段，分析设计作为一个软件产生的龙头，有着映射实际需求世界 到计算机世界这样一个拷贝任务，如何做到拷贝不走样，是衡量映射方法好坏与否的主要判断标准。
目前，将需求从客观现实世界映射到计算机软件世界主要有两种方式：传统数据库分析设计和面向对象建模( object-oriented class model)， 当前软件主要潮流无疑是面向对象占据主流，虽然它可能不是唯一最好最简单的解决方案，但是它是最普通，也是最恰当的。
也就是说：在分析设计阶段，采取围绕什么为核心(是对象还是数据表为核心)的分析方法决定了后面编码阶段的编程特点，如果以数据表为核心进行分析设计， 也就是根据需求首先得到数据表名和字段，然后培训程序员学会SQL语句如何操作这些数据表，那么程序员为实现数据表的前后顺序操作， 必然会将代码写成过程式的风格。
相反，如果分析设计首先根据需求得出对象模型(class Model)，那么程序员使用对象语言，再加上框架辅助，就很顺理成章走上OO编程风格。 至于OO代码相比传统过程编码的好处不是本文重点，可参考J道(jdon.com)相关讨论，扩展性和维护性好，开发越深入开发速度越快无疑是OO系统主要优点。
本文重点主要是比较OO建模和数据表建模两者特点，这两者我们已经发现属于两个不同方向，也就是说，属于两个完全不同的领域，在J道其他文章里我们 其实已经把这两个领域上升为不同的学科，数据表建模属于数学范畴思维；而OO建模属于哲学思维。
下面我们看看面向对象的Class Model和Database Model是如何来表达客观世界的，也就是他们在表达需求上有些什么不同？
面向对象模型(Class Model)
类代表一个对象类型，类在代码运行阶段将被创建为一个个对象实例， 每个类由两个部分组成：属性和行为，属性通常是一些数据状态值，也就是说：类将数据封装隐藏在自己内部了， 访问这些数据属性必须通过类公开的方法，或者接口。
别小看这样一个小小包装，却决定了以后代码的维护性和扩展性， 打个比喻，日常生活中我们经常用各种盒子和袋子包装一些东西，这样做就是为了方便这些东西的携带或储藏，小到生活， 大到客观世界每个地方，都是包装分类的影子，无论大小公司都是一个封装，行政部分单位划分，仓库物流更需要包装， 我们从来不会因为嫌麻烦而不愿意引入一个似乎多余的盒子或袋子，那么有什么理由不在我们赖之生存的软件中（靠编软件吃饭） 引入封装概念呢？
这里可以再深入想像一下：不愿意用盒子和袋子的携带东西大部分是一些急脾气的毛头小伙子，而偏偏这些小伙子又从事 软件工作，看来软件的非对象化是注定的，只是一个玩笑。
类的方法行为也有多种类型，如公开 私有等，我们可以设计一些方法为公开接口，而将另外一些行为隐藏起来， 这样一个看似简单灵活的选择，却能够应付我们日后频繁的修改，软件不修改就不叫软件，软件修改了就崩溃是业务软件， 专业的软件是抗修改的，而且能够极其方便快速地被修改。这些都依靠接口公开和隐藏这样一个简单魔术。
类的关系
我们不能只用一个一个单独的类来表达客观世界，因为客观世界存在千丝万缕的各种关系，在计算机领域无疑我们使用 类的关系来表达映射这些关系。这里我们只探讨类在建模方法上的关系，而不是UML中类的通用关系。 类在建模上主要有如下几个关系：
类与类关系经常是这样：一个类包含一个类(构造性structural)，或者借助另外一个类达到某个功能（功能性）， 在对需求建模分析中，构造性的这种关系，也称为关联(Association)是我们关注重点，当然这种关系很显然表达的是一种 静态的结构，比如电脑包含屏幕，他们之间的关系就是一种关联。
聚合(Aggregation)是一种表格式样的关联，表示一个类包含多项子类，这种关系是一种整体与部分的关系。 一个汽车有四个*，四个*是汽车的部分。
组成(Composition)是一种更强烈的聚合关系，一个对象实际是由其子对象组成，子对象也唯一属于父对象。
继承也是类建模中经常用到的关系，继承可以将一些数据属性抽象到父类中，避免重复，如入库单和出库单有 很多属性是差不多的，唯一不动的就是入库和出库的行为，那么我们可以抽象一个库单为父类，使用继承关系分别 表达入库单和出库单。
好了，下面我们谈论关系数据表模型，以前我们朴素的分析设计都是根据需求直接建立数据表的方式来进行的，为什么称为朴素， 是因为我们好像只有数据结构 算法方面的知识，也认为只有这样做才叫做软件。 那么既然这条路能够走出来，我们看看这个领域是如何映射客观世界的。
数据表由于技术提供庞大数据存储和可靠的数据访问，正在不断从技术领域走向社会领域，很多不懂计算机的人 也知道需要建立数据库来管理一些事务，但是不代表我们就必须围绕数据库的分析设计。
数据表是类似前面的“类”，也是一种表达客观世界的基本单元，表有多列字段，表的字段是保存数据的，每个字段有数据类型。 注意，这里没有数据的封装和公开，表的字段是赤裸的，只要有数据库访问权限，任何人都可以访问，没有结构层次关系， 都是扁平并列的，如果你想在数据表字段之间试图看出客观世界中的层次和封装，那就错了，在拷贝不走样这个条件下， 这个映射方法至少把这个信息拷贝丢了。
数据表也有一些行为，这些行为是基于实体的一些规则：
约束(Constraints) 能够保证不同表字段之间的关系完整安全性，保证数据库的数据安全。
触发器(Triggers)提供了实体在修改 新增和删除之前或之后的一些附加行为，
存储过程(Database stored procedures)提供数据专有的脚本性语言，存储过程象一个数学公式虽然具有抽象简洁美学，但是这种简洁是闷葫芦美学，不是大众美学，只有公式存储 过程发明者自己了解精通，别人无法插手，软件不是科学，不是比谁智商高，科研水平高，软件是人机工程，更讲究集体，讲究别人是否方便与你协同扩展软件。
关系数据表的遍历访问是通过列字段遍历或表join等方式实现，SQL语句是这样标准语言， 只要会写SQL语句，就能访问那些失去层次，失去客观世界特征的苍白的数据，这样的系统能够多少真实 反映客观需求，是有问号的？SQL语句是否方便修改，是否经得起频繁修改而不出错，都是有疑问的地方，是否 SQL语句越复杂，修改越快，或者另外一个程序员能够很快修改不是自己写的SQL语句，这些都是问题所在。
数据表关系
数据表的关系主要是通过外健或专门关联表来表达的，这种关系虽然可以反映1:1或1:N这样关系，但是无法 表达关系的性质，是紧密组成关系式的关联，还是无关紧要的普通关系，正因为如此，使用数据表分析设计时， 我们会有蜘蛛网的关系表，这些关系由于在后期无法分辨性质，无法进行整理，增加了系统复杂性。
更重要的是：分析就是对一个可能陌生领域进行探寻，如果使用数据表的分析设计方法，那么我们实际就是 在陌生领域中寻找数据表这样一个形式，那么有可能产生误判断，将一个实则是表达关系的东东误认为是一个实体表， 因为关系表必然带来关系，这样，就必然产生蜘蛛网式的数据表模型，将简单问题复杂化。
总结
要谈方法，这个世界其实只存在两种：一是将复杂问题简单化的方法；一个是将简单问题复杂化的方法。 你使用什么样的方法，你就有什么样的世界观，就是什么样的人，但是对于软件这个领域，你只能选择前者。
因为方法的不同，软件路线也就存在下面几个路线：完全面向对象类建模路线(J道网站和笔者一直致力于这种路线的推介)； 一种是对象和关系数据库混合型，还有一种就是过去的完全关系数据库类型软件（如Foxpro/VB/Delphi等）。
面向对象与领域建模：
我也是引用的别人的
多变且复杂的需求
如果没有多变的需求，也许就没有今天的面向对象软件，我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击，可是这样下去的结果只有一个：使得软件更加僵化；或者程序员更加 劳累。
需求不但多变，而且经常是不可能第一次就能掌握，需求反映了某个领域的专业知识，例如数学、管理、财务或 电子商务等等，每个特定案例需求又有其特别复杂之处，几乎没有人能够第一次接触就可以深入掌握这些专业领域的 需求本质，就是专门的建模专家也不例外。
既然需求是多变而且复杂的，所以，就不能使用“堵”式方法对其进行控制和管理，只能顺势而为，通过灵活多变的 以及迭代反复的方式逐步抓住需求，并且作为需求的实现软件系统必须能够迅速应对需求变化，需求变化有多快，软件 变化就有多快。
因此，对于多变的需求，我们的解决之道是：引入灵活多变的架构，面向对象OO架构正是应对多变需求而生，强调软件的可维护性 和拓展性，OO可能不是最好方式，但是目前是最合适的；对于复杂的需求，我们的解决之道是：委派专门的建模专家跟踪理解需求， 在需求和需求实现之间搭建桥梁，项目方法上采取多次迭代的敏捷软件开发方式，逐步了解学习掌握需求。
在这里稍微说明一下，很多人总是将软件和数学、管理、财务混为一谈，其实软件本身就是一门独立的专业，是为 数学、管理。财务等专业领域服务的，不能期望软件人员也是其他领域专业人员，可是在中国现实中，很多人总是 无法分辨，例如某局长将整个机关考核信息化的任务交给电脑中心，这就是将考核管理专业和软件专业混同的例子， 在考核管理和软件之间需要一个领域建模专家，由他来理解或者设计考核管理体系，然后通过模型，表达成 软件人员能够看懂的符号，软件人员通过模型了解领域。
曾经有需求专家呼吁：最好将需求给所有软件人员都了解，需求专家和一般软件人员一起工作，这些想法的本质是 好的，但是不可能实现的，不可能每个软件人员不但了解软件架构和OO思想；还能够掌握另外一个专业领域的艰深知识， 所以，现在我们提出：将领域专家建立的统一领域模型让所有软件人员都了解，让一般软件人员围绕领域模型工作，这样 的方式才切实可行。
需求分析方法演变
历史上，对需求分析方法可以说经过三个阶段：
第一阶段：围绕数据库的驱动的分析设计，新软件项目总是从设计数据库及其字段开始。这个阶段特征就是围绕数据库编程，典型的是 DBase/Foxpro，以及后来的Delphi/VB技术。
这种围绕数据库分析设计的缺点非常明显：首先，不能迅速有效全面认识反映需求，世界不只是由简单的关系数据组成，而且 使用关系数据来反映现实需求，不符合人类自然思维（OO才是），是一种扭曲的分析方法，特别对于初学者，他们接受数据库分析方法的难度反而可能会大于OO分析方法，现在很多职业学校和社会培训，基础课程从数据库开始，从某种程度上，是历史倒退， 严重阻碍中国软件发展的进程。
围绕数据库分析极其容易导致过程化设计编程，围绕数据分析和过程化编程是一对恶魔，数据库结构确立后，就让普通程序员写SQL 语句，SQL语句执行有明显的先后顺序，在这样顺序过程编程思维中，OO思维就难以生存。长此以往，成为习惯后，就很难改变到 OO设计上，所以，传统编程经验越丰富，转变到OO设计就越难。
在运行性能方面：围绕数据库分析设计容易导致软件运行时负载集中在数据库端，系统性能难于扩展（走上集中式、昂贵的、高风险的大型机模式）， 闲置了中间件J2EE服务器分布式集群处理能力，就是使用了集群，也分担不了负载。
最后，我们必须认识到：对象和关系数据库存在阻抗，本身是矛盾竞争的，他们是两种分析看待需求的流派，可以说是水火不容， 要么你采取数据库分析设计以及过程化编程，要么完全采取OO，现在使用.NET和Java这样OO语言的人很多，但是70%左右都是使用OO语言
编写传统过程化系统，在Java中这样做，会有极差性能；而这种现象在.NET中又极容易得到纵容，.NET是一个系列阵营，正如Windows系列一样， 当你和别人说，你在使用Windows，别人可能觉得你没有落后时代，但是他们哪里知道你在使用Windows 3.1呢？
第二阶段：面向对象的分析设计方法诞生后，有了专门的分析和设计阶段之分，我们使用UML符号来表达分析设计思想，分析设计进入了一个相对更高的层次，拥有了自己一套科学且艺术的方法论。但是有一个致命缺点：分析阶段和设计阶段是断裂的，互相不能很好衔接，为什么？
首先，我们看看分析人员和设计人员在职责重点工作是什么？
分析人员的职责：是负责从需求领域中收集基本概念。而设计人员的职责：必须指明一组能北项目中适应编程工具构造的组件，这些组件必须能够在目标环境中有效执行，并能够正确解决应用程序出现的问题 两个阶段两者目标不一致，分析人员只管需求分析，至于是否适合设计，或者能够导出适宜设计的分析结果，这个尺度很难衡量和把握；
而设计人员因为照顾代码可运行，因此，经常可能会抱怨分析员给出的结果过于粗糙，不适合设计，这样分析设计两个阶段就导致分裂，项目失败。
在这个阶段，虽然有UML帮助，但是UML不是思想，打个比喻：会CAD的绘图员就是建筑师吗？很显然，UML就是CAD图符号，UML不等于分析设计思想。 所以，有人说UML不是银弹，这些就象说中医不是科学一样绕人（中医就不是西医，当然就不是科学）。
第三阶段：融合了分析阶段和设计阶段的领域驱动设计（Evans: DDD）。2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计 ）简称Evans DDD， 领域建模是一种艺术的技术，它是用来解决复杂软件快速应付变化的解决之道，所以，从Evans DDD通篇文章中，你找不到科学象征的定理和公式，当然如果 你试图寻找这样寻找，你也就陷入了“中医是不是科学”怪圈了。
Evans DDD抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。这就是领域模型。 单一的领域模型同时满足分析原型和软件设计 ，如果一个模型实现时不实用，重新寻找新模型。如果模型没有忠实表达领域关键概念时，也必须重新寻找新的模型。 建模和设计成为单个迭代循环。将领域模型和设计紧密联系。因此，建模专家必须懂设计。
领域建模的重要性
如果你说一个软件开发需要经过需求、分析和设计三个阶段的话，那么可能反映你的思想已经落伍，软件开发现在是 经过需求、建模阶段，混合了分析和设计阶段，可以更激进地说：我们国家的系统分析员和系统设计员考试也许应该合并了， 合并成建模专家的考试，否则，这些都是中国软件落后世界十年的证据，可悲的是：我们自己可能都不知道。
Evans DDD可以说是近期与SOA相提并论的两大重要技术思想，SOA是着重于软件集成方面；而EvansDDD才是着重我们软件开发上， 在大部分情况下，软件开发重要程度不亚于软件集成，但是因为软件开发方面开源力量冲击，软件集成上工业厂商利润最高， 所以，工业厂商在SOA叫得最响，我们参加得各种会议几乎都是SOA，当心被误导，工业厂商从来不会告诉你事实得争相。
没有面向对象的分析设计，哪里面向对象的构件或组件？过去经验不是证明：我们使用大量的构件组件，却在编制面向过程的体系？
以EJB2为例子，在EJB2过去大部分系统中，我们常常以数据库为中心，实体Bean因为特殊技术原因，僵硬一块，变成数据库 的代名词，我们围绕实体Bean编制出大量的值对象Vale Obejct，或称为DTO（Data Transfer Object），在这样系统中，从对象 的名称也可以看出，对象是为数据服务的，对象从属于数据库的。
现在，要彻底改变过来，OO就是以对象为主，数据库是从属对象设计的，如果说EJB2的实体bean技术让你不得不走上传统过程化编程歧路，那么 EJB3已经更正了实体Bean设计缺陷，从EJB发展可以看到一个侧面：工业厂商更多关心的是功能，而不是设计？
只有谁才真正关心你的软件设计和代码质量？只有你自己。我不是提倡都不要参加工业厂商的会议，而是需要每个人冷静想想： 到底谁是自己代码的主人？
领域建模属于与具体.NET或Java技术无关的设计思想，有人总是说：.NET比Java简单，其实这又是一个大误区，如果都达到同样设计水准，无论使用.NET或Java，都需要付出同样的努力；那为什么有人觉得.NET简单，那是因为设计要求降低了，参见这篇.NET的DDD文章。
分层架构
分层架构是现代OO软件企业系统的基本架构，只有分层才能达到良好的可拓展性和维护性。基本三层：表现层、业务层和持久层 ;J2EE中表现层和持久层有成熟框架支持，应用重点在业务层。
业务层根据Evans DDD，可以再细分为应用层和领域层两种，在业务层设计编码中，大量应用OO设计原则和设计模式。领域层定义：负责表达业务领域概念、业务状态以及业务规则，是整个业务软件核心和重点。 应用层定义：负责完成功能，并且协调丰富的领域对象来实现功能，不能包括业务规则，无业务状态；
每个层都是内聚的，并且只依赖它的下层，为了实现各层的最大解耦，IOC/DI容器是当前Java业务层的最好选择 。
没有分层架构的快速开发基本是旁门左道，不如返回Foxpro和Delphi/VB两层时代。将本属于业务层的逻辑交由表现层来处理的快速UI方式也是一种旁门左道。快速开发必须基于良好的质量，虽然良好的分层架构带来开发效率的降低，但是这些也是可以有方法解决。
建模与项目管理
在我们大多数从软件项目管理上寻找软件永恒解决之道时，他们可能没有意识到又在范“缘木求鱼”老毛病了， 打个比喻很容易明白这个道理：冷兵器时代（也就是火枪没有没有发明之前），各种排兵布阵可能在作战指挥时 很有效；但是到了火器时代，所有的过去作战方式就落伍了；当然到了现在信息化战争时代，更是天壤之别。
Evans DDD领域驱动建模的诞生，对过去传统的项目管理都提出挑战，当我们还在争论RUP好还是敏捷好的时候， 谁会想到我们应该采取围绕统一领域模型的迭代驱动开发呢？
有人可能还在疑惑？我接到一个大项目，那么我的建模和架构设计时间应该是5个月还是5年呢？当然应该回答他：都不行，需求是多变且复杂的，计划赶不上变化，现在就应该开始DDD建模。