Evans DDD(领域驱动开发) 与架构分层

名词解释: Evans DDD - Domain Driven Development 领域驱动开发

引子:

记得原来都喜欢讨论分层的好处,无非是为了独立业务,业务下面还有一层数据操作层,而往往将数据中的字段与实体进行一一对应,于是有了

表现层 -> 业务逻辑 -> 数据访问

这样对吗?

对,也不对,原因在于业务逻辑并没有划分清楚,数据访问所指何物呢?

如果换成下面这样的业务对象也许会好一点

表现层 -> 业务逻辑 -> 持久层 -> 数据库

开发模式的改变:

个人过去其实一直不太理解数据访问所指何物,于是有了实体一般就是数据库表的对应,而各种ORM似乎也在变相的支持这种说法,各种表直接对应生成实体。那对于业务逻辑这一层来说不可避免的要和数据库对应,这样的情况下,数据库实际上是在变相的决定了业务逻辑的走向,对于面向需求的开发来说,这种开发模式无疑是一大害处, 或者换个角度,面向关系的数据库实际导致了我们的开发也不是OO。

对于用例或者说需求确定者来说,他们参与到业务逻辑中来,他们确定一个业务的领域与实体对象,而不关心数据库的生成与管理,这样数据库就可以和业务分开, 在Java社区似乎这样的东西已经有很多,于.Net现在也有了一个Evans DDD的产物,ADO.NET Entity Framework。将实体变成数据库在业务逻辑中的映射,这样,开发人员打交道的是业务实体,而数据库则由专门的人员来管理,确定职责划分。业务逻辑确定持久层确定的好,开发人员开发的效率将会越来越高

而核心的持久层的设计应该是根据各个业务的不同规则进行设计,当各个实体确定的时候,数据库是怎样就让数据库设计人员去把握吧, 领域专家来设计业务对象。

posted on 2008-06-07 12:58  xwang  阅读(2470)  评论(2编辑  收藏  举报

导航