名词解释: Evans DDD - Domain Driven Development 领域驱动开发
引子:
记得原来都喜欢讨论分层的好处，无非是为了独立业务，业务下面还有一层数据操作层，而往往将数据中的字段与实体进行一一对应，于是有了
表现层 -> 业务逻辑 -> 数据访问
这样对吗?
对，也不对，原因在于业务逻辑并没有划分清楚，数据访问所指何物呢?
如果换成下面这样的业务对象也许会好一点
表现层 -> 业务逻辑 -> 持久层 -> 数据库
开发模式的改变:
个人过去其实一直不太理解数据访问所指何物，于是有了实体一般就是数据库表的对应，而各种ORM似乎也在变相的支持这种说法，各种表直接对应生成实体。那对于业务逻辑这一层来说不可避免的要和数据库对应，这样的情况下，数据库实际上是在变相的决定了业务逻辑的走向，对于面向需求的开发来说，这种开发模式无疑是一大害处, 或者换个角度，面向关系的数据库实际导致了我们的开发也不是OO。
对于用例或者说需求确定者来说，他们参与到业务逻辑中来，他们确定一个业务的领域与实体对象，而不关心数据库的生成与管理，这样数据库就可以和业务分开, 在Java社区似乎这样的东西已经有很多，于.Net现在也有了一个Evans DDD的产物，ADO.NET Entity Framework。将实体变成数据库在业务逻辑中的映射，这样，开发人员打交道的是业务实体，而数据库则由专门的人员来管理，确定职责划分。业务逻辑确定持久层确定的好，开发人员开发的效率将会越来越高
而核心的持久层的设计应该是根据各个业务的不同规则进行设计，当各个实体确定的时候，数据库是怎样就让数据库设计人员去把握吧, 领域专家来设计业务对象。