本文的初衷是想浅谈一下领域模型驱动中表的设计方法（本文O/R Mapping 结构部分）。结果发现没法脱离开O/R Mapping的其他知识点来讲这个。所以 O/R Mapping 的东西就越说越多。
先说分层
在面向对象的开发中，我们通常会使用分层开发。三个基本层次结构如下。
|
层次 |
职责 |
|
表现层 |
提供服务、显示信息 |
|
领域层（业务逻辑） |
逻辑、系统中真正的核心 |
|
数据源层 |
与数据库、消息系统、事务管理器及其他软件包通信 |
分层基本原则
领域层和数据源层绝对不要依赖于表现层；
最困难的事情-----区分领域逻辑
什么是领域逻辑，什么是其他逻辑？
测试办法：抽、换
更换表现层：假设向系统中增加一个完全不同的新层，如果发现需要重复实现某些功能，则说明可能有一些本应该在领域层实现的逻辑，现在在表现层实现了。
更换数据源层：同理，可以将后台数据库更换为XML文件格式。
领域逻辑组织方式
三种主要模式：事务脚本、领域模型和表模块。
事务脚本
最简单的模式，从表现层获得输入，进行简单校验和计算处理，将数据存储到数据库中。
表模块
围绕表而非直接围绕过程来组织领域逻辑。系统设计时已经假定与SQL查询的返回结果协同工作。
在.NET开发中很多人都使用代码生成器其实就是表模块模式。
领域模型
在领域模型中，不再是由一个过程来控制用户某一动作的逻辑，而是每一个对象都承担一部分相关逻辑。
关于领域模型开发，有两件事情是必须要面对的。
1）如何设计对象模型？
2）如何映射为数据库？
再说O/R Mapping
一）构架 领域逻辑访问数据库的方式？
二）行为 如何让各种对象从数据库中读取出来以及存到数据库中？
三）结构 如何把表和对象联系起来？
构架
要解决的问题：驱动领域逻辑访问数据库的方式。
入口方式：分离SQL访问，使用独立的类为数据表建立入口。每个数据表对应一个类，应用程序通过这个入口实现SQL访问。
入口的两种方式
行数据入口：为SQL查询返回的每一行数据产生一个对象的实例。
在.NET中可以理解为，find(id) 对应一个 DataRow
表数据入口：用一个对象来对应一个数据表。
表数据入口与记录集非常匹配，成为使用表模块的首选。
在.NET中可以理解为，find(id) 对应一个 DataTable
活动记录：在简单应用中，领域模型与数据表结构一致，可以让每个领域对象负责数据库的存取过程。没有必要再增加一个入口（customer Gateway）。
数据映射器：
随着领域逻辑复杂度的增加，比较好的持久化机制是使用数据映射器。它把领域模型和数据库完全独立，由数据映射器完成领域对象和数据表之间的映射。
综上，领域模型持久化机制可以选择活动记录（简单应用）和数据映射器（复杂应用）。
行为
要解决的问题：如何让各种对象从数据库中读取出来以及存到数据库中。在这个过程可能会出现内存中数据与数据库的同步问题。解决这个问题的方法就是使用工作单元。
工作单元
跟踪所有从数据库读取的对象以及所有修改过的对象，同时负责将更新提交到数据库。
1）应用程序把工作交托给工作单元，而不是直接调用明确的保存方法。工作单元排列好对数据库的操作顺序。
2）充当数据映射器的控制器，在没有工作单元的情况下，由领域层充当控制器。
3）从领域逻辑中分解出来，负责数据一致性控制的控制对象。
延迟加载
产生背景
如果使用了领域模型，就必须合理安排，使得关联的对象一起加载。然而，如果许多对象都是连接在一起的，则读取任何对象都会从数据库中带出大批对象。为了避免这种低效，就必须设法减少带出来的东西，当然，还需要保持接口以便在以后需要的时候再读出来。
主要思想
拥有一个对象的占位符，可以采用几种方法，但它们的共同点是拥有被修改对象的对象引用，它指向的是一个占位符，而不是实际的对象。当且仅当需要的时候，才会从数据库中读取对象。
结构
要解决的问题：如何把表和对象联系起来？
对象之间的关系可能是一对一、一对多和多对多的。在领域模型中这些存在关系的对象又是怎样映射到数据库中的呢？这里有一个关键问题是对象和关系型数据库处理连接的方法不同。
1）表现方法不同：对象是通过在运行时中保存引用的方式来处理连接。（对象引用）
关系数据库是通过创建到另外一个表的键值来处理连接。（外键引用）
2）对象可以很容易通过集合来表示多个引用，而关系数据库中的连接必须是单值的。这就导致对象和表之间的数据机构完全不同。
例如，一个订单对应多个订单项的关系。
对象处理方式：一个订单对象会拥有一个订单项的集合。而这些订单项不需要持有订单对象的引用。
表处理方式：表结构中的各订单项必须包含一个到订单的外键，因为订单不能有一个多值域用来包含所有的订单项。
下面详细介绍各种关系的解决办法。
一对一关系
通过对象中的一个标识域来保持每个对象的关系特征，并且通过查找这些值来保持对象引用和关系键之间的相互映射。
一对多关系
如果对象包含一个集合，则必须构造一个新的查询来找到所有与源对象的ID相关的行
（可通过延迟加载来避免查询）。创建每个返回的对象并加入到集合中，对这个集合的保存包含：保存每一个对象，并且保证它拥有一个到源对象的外键。
多对多关系
两边都存在集合，如学生与课程。一个学生可以学多门课程，一个课程有很多学生在学习。
关系数据库不能直接解决这种问题，需要使用关联表映射来创建一个新的关系表用来解决多对多的问题。
使用关联表映射来映射一个多对多的关联
对象关系持久化方式
1）上面使用标示域用来把对象间引用变成外键。
2） 可以将一组对象存储为表中的单个列，为了便于查询这个列中的内容，可以存储为XML。这样在SQL调用中可以使用XPath查询。
继承关系
上面处理的是将对象的组合关系映射到关系数据库。下面看看继承关系如何映射！
三种选择
1）单表继承：可以为一个层次中的所有类建立一个表。
2）具体表继承：为每个具体类建立一个表。
3）类表继承：为一个层次中的每一个类建立一个表。
比较
1）单表继承好处是把所有内容放在一起，修改起来容易并且避免了Join操作。问题是浪费空间以及表体积太大。
2）具体表继承避免了Join操作，允许从一个表中取得一个对象，但是改变起来比较困难。 对超类的任何改变都需要改变所有的表。
3）类表继承是类和表之间最简单的关系。但是需要Join操作，损失性能。
综述
使用领域模型时，不必理会数据库。关注于领域逻辑的设计，把数据库设计看成是持久化对象数据的方法。但不应当在很长的一段时间内（如，半年）只设计没有数据库的领域模型。一旦持久化的时候可能会出现问题，正确的做法是设计领域模型时，迭代构建数据库。
参考内容：
1、《企业应用构架模式》