小议领域模型(Domain Model)补充以及更新

Author:Anders小明

为何要DomainModel

传统的开发方式：基于数据库的设计开发。数据库提供的设计模型是表和字段两种粒度，这两种粒度有时并不合适于系统设计：

1.模型的结构化能力

1.1.同一模块组件下的设计优势；一个model可以来自多张表的数据聚合而成，一张表可以聚合多个Model；一个逻辑是由几个固定字段或者非固定字段聚合；Model间的关联关系也是使用表无法展示的（外键的约束对于系统开发来说实在太有限了）。而这些不论表还是字段粒度都无法支持的！

1.2.采用Model方式容易解决项目的集成问题（两个不同模块组件访问同一张表的情况）

2.架构的结构化能力

事务脚本直接访问到表。换句话说，其架构只有Service+DatabaseTable，这样的架构下DatabaseTable可以说就是我们的模型。

这里看看在逻辑设计上DomainModel对于架构影响

A.Service，Model和Repository，model的重建和关联交由Repository完成，单个数据逻辑交给Model（支持泛化）

B.测试的好处

3.分析和设计的统一

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

4.其它好处

4.1.采用DomainModel可以屏蔽持久化信息。持久化设计的表设计是和DBA相关的，DBA对于表设计有权力的，采用Model可以有效隔离各自工作；

4.2.Model可以通过很多的手段透明的解决性能问题，而采用表做模型导致容易导致性能问题，当然不是没有办法解决，一种是通过DataSet的方式，但这样的切换成本较高。

应用Domain的体系结构

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

以下是示意图：

DomainService|Repository

DomainObject|

Repository和Dao

Repository是一种特殊的Service，不做任务处理；而是提供Model的持久化，重建和查询工作。由于企业应用大都通过数据库实现持久化，因而Repository和传统的Dao间的集成设计就非常重要。

已知的有三种设计方式：

1.两个接口两个实现类。Repository和Dao各自独立接口，而通过Repository实现类转发请求给Dao实现类。

这种方式虽然正统，但是维护成本太高；一次更新最多要改四处地方。

2.两个接口一个实现类。Repository和Dao各自独立接口，一个实现类同时实现两个接口。

这种方式就大大简化维护成本；一次更新最多只改一个接口和一个实现类。

3.两个接口一个实现类。与上面不同是，Dao接口继承Repository接口，一个实现类实现Dao接口。

这种方式的维护成本和上一种差不多，但是当接口方法在这个两个接口间流动时，可以通过开发工具完成。

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