Author: Anders小明

为何要Domain Model
 传统的开发方式：基于数据库的设计开发。数据库提供的设计模型是表和字段两种粒度，这两种粒度有时并不合适于系统设计：
 1. 模型的结构化能力
 1.1. 同一模块组件下的设计优势；一个model可以来自多张表的数据聚合而成，一张表可以聚合多个Model；一个逻辑是由几个固定字段或者非固定字段聚合；Model间的关联关系也是使用表无法展示的（外键的约束对于系统开发来说实在太有限了）。而这些不论表还是字段粒度都无法支持的！
 1.2. 采用Model方式容易解决项目的集成问题（两个不同模块组件访问同一张表的情况）

 2. 架构的结构化能力
 事务脚本直接访问到表。换句话说，其架构只有Service + Database Table，这样的架构下Database Table可以说就是我们的模型。
 这里看看在逻辑设计上Domain Model对于架构影响
 A. Service， Model和Repository，model的重建和关联交由Repository完成，单个数据逻辑交给Model（支持泛化）
 B. 测试的好处

 3. 分析和设计的统一
 沟通的问题，客户关注于其业务，分析的模型接近于客户需求，设计也采用model的方式，避免分析和设计的割裂。有助于IT间，IT和BA（客户）间的沟通

 4. 其它好处
 4.1.采用Domain Model可以屏蔽持久化信息。持久化设计的表设计是和DBA相关的，DBA对于表设计有权力的，采用Model可以有效隔离各自工作；
 4.2.Model可以通过很多的手段透明的解决性能问题，而采用表做模型导致容易导致性能问题，当然不是没有办法解决，一种是通过DataSet的方式，但这样的切换成本较高。

 应用Domain的体系结构
 如前所述，逻辑设计上Domain Model的实施使得架构分为Service，Model和Repository；其中 Model的持久化，重建和关联交由 Repository完成；而单数据逻辑（依赖自身数据信息以及关联数据）则归于 Model（支持泛化）； Service则关注于任务处理，相当于一个 macro flow，包括了多个 model处理，以及其它服务的调用。
以下是示意图：
 Domain Service  | Repository
 Domain Object   |

Repository和Dao
 Repository是一种特殊的Service，不做任务处理；而是提供Model的持久化，重建和查询工作。由于企业应用大都通过数据库实现持久化，因而Repository和传统的Dao间的集成设计就非常重要。
已知的有三种设计方式：
 1. 两个接口两个实现类。Repository和Dao各自独立接口，而通过Repository实现类转发请求给Dao实现类。
 这种方式虽然正统，但是维护成本太高；一次更新最多要改四处地方。
 2. 两个接口一个实现类。Repository和Dao各自独立接口，一个实现类同时实现两个接口。
 这种方式就大大简化维护成本；一次更新最多只改一个接口和一个实现类。
 3. 两个接口一个实现类。与上面不同是，Dao接口继承Repository接口，一个实现类实现Dao接口。
 这种方式的维护成本和上一种差不多，但是当接口方法在这个两个接口间流动时，可以通过开发工具完成。

 另外Dao实现类本身也是工作中开发维护成本较高的一部分，可以通过代码生成降低开发成本，更多资料可以参考ibatis。