小议领域模型(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。

相关推荐