领域驱动设计之设计分层架构
2013-05-07 10:03
441 查看
以前的设计
首先我们回顾下以前我们设计系统的做法。在过去,我们的应用程序架构一直以数据为中心。我们的核心是围绕数据库展开的,首先我们会建立数据库,建立一系列的数据表,数据库表之间的主外键关系表述整个系统中的对象之间的关系。数据表中的一行数据来表述一个对象。然后我们会依次建立数据访问层、业务逻辑层、表现层。如下图所示
注:此图来源 /article/4757554.html
注意图中打虚线的“基础结构层”,从实践的表现上来看,这部分内容可能就是一些帮助类,比如 SQLHelper之类的,也可能是一些工具类,比如TextUtility之类。这些东西可以被其它各层所访问。
表现层、业务逻辑层、数据访问层是一种自上而下的调用关系。表现层只能与业务逻辑层打交道,而业务逻辑层在数据持久化方面的操作,则依赖于数据访问层。表现层对数据访问层的内容一无所知。
1.基础结构层可能包含业务逻辑处理,会使业务逻辑层和基础结构层之间的职责重合
2.过分强调数据的状态,忽略对象之间的关系(或者说是数据库不能很好地表现对象与对象之间的关系)及约束,领域驱动设计中聚合能更好的处理这一点。
3.业务逻辑层不能很好地表现业务逻辑,很多时候我们的业务逻辑层只是对数据访问层的包装(增删改查),模型是失血模型,很多时候模型和dto是一体的。模型扮演了多个角色。
此种设计的典型是微软的petshop,不过微软的petshop业务比较简单,应用此种设计比较合适
领域驱动设计的分层
从此图可以看出 领域驱动设计的层次结构也是4层:基础结构层、表现层、应用层、领域层。与上面相比,数据访问层已经不在了,它被转移到了基础结构层。注意领域层中的Repository是仓储的接口,并非真正的仓储实现。
基础结构层:该层专为其它各层提供技术框架支持。这部分内容不会涉及任何业务知识。数据访问的内容也被放在了该层当中,因为数据的读写是业务无关的,只是对象状态的持久化与重建。
领域层:包含了业务所涉及的领域对象(实体、值对象)、领域服务以及它们之间的关系。这部分内容的具体表现形式就是领域模型(Domain Model)。领域驱动设计提倡富领域模型,即尽量将业务逻辑归属到领域对象上,实在无法归属的部分则以领域服务的形式进行定义。
应用层:该层不包含任何领域逻辑,但它会对任务进行协调,并可以维护应用程序的状态,因此,它更注重流程性的东西。在某些领域驱动设计的实践中,也会将其称为“工作流层”。应用层是领域驱动中最有争议的一个层次,也会有很多人对其职责感到模糊不清。
表现层:这个好理解,跟三层里的表现层意思差不多,但请注意,表现层中的“Web服务”虽然是服务,但它是表现层的东西
从上图还可以看到,表现层与应用层之间是通过数据传输对象(DTO)进行交互的,它的目的只是为了对领域对象进行数据封装,实现层与层之间的数据传递。
因为领域对象更注重领域,而DTO更注重数据。不仅如此,由于“富领域模型”的特点,这样做会直接将领域对象的行为暴露给表现层。
文章引用:/article/4757554.html
首先我们回顾下以前我们设计系统的做法。在过去,我们的应用程序架构一直以数据为中心。我们的核心是围绕数据库展开的,首先我们会建立数据库,建立一系列的数据表,数据库表之间的主外键关系表述整个系统中的对象之间的关系。数据表中的一行数据来表述一个对象。然后我们会依次建立数据访问层、业务逻辑层、表现层。如下图所示
注:此图来源 /article/4757554.html
注意图中打虚线的“基础结构层”,从实践的表现上来看,这部分内容可能就是一些帮助类,比如 SQLHelper之类的,也可能是一些工具类,比如TextUtility之类。这些东西可以被其它各层所访问。
表现层、业务逻辑层、数据访问层是一种自上而下的调用关系。表现层只能与业务逻辑层打交道,而业务逻辑层在数据持久化方面的操作,则依赖于数据访问层。表现层对数据访问层的内容一无所知。
1.基础结构层可能包含业务逻辑处理,会使业务逻辑层和基础结构层之间的职责重合
2.过分强调数据的状态,忽略对象之间的关系(或者说是数据库不能很好地表现对象与对象之间的关系)及约束,领域驱动设计中聚合能更好的处理这一点。
3.业务逻辑层不能很好地表现业务逻辑,很多时候我们的业务逻辑层只是对数据访问层的包装(增删改查),模型是失血模型,很多时候模型和dto是一体的。模型扮演了多个角色。
此种设计的典型是微软的petshop,不过微软的petshop业务比较简单,应用此种设计比较合适
领域驱动设计的分层
从此图可以看出 领域驱动设计的层次结构也是4层:基础结构层、表现层、应用层、领域层。与上面相比,数据访问层已经不在了,它被转移到了基础结构层。注意领域层中的Repository是仓储的接口,并非真正的仓储实现。
基础结构层:该层专为其它各层提供技术框架支持。这部分内容不会涉及任何业务知识。数据访问的内容也被放在了该层当中,因为数据的读写是业务无关的,只是对象状态的持久化与重建。
领域层:包含了业务所涉及的领域对象(实体、值对象)、领域服务以及它们之间的关系。这部分内容的具体表现形式就是领域模型(Domain Model)。领域驱动设计提倡富领域模型,即尽量将业务逻辑归属到领域对象上,实在无法归属的部分则以领域服务的形式进行定义。
应用层:该层不包含任何领域逻辑,但它会对任务进行协调,并可以维护应用程序的状态,因此,它更注重流程性的东西。在某些领域驱动设计的实践中,也会将其称为“工作流层”。应用层是领域驱动中最有争议的一个层次,也会有很多人对其职责感到模糊不清。
表现层:这个好理解,跟三层里的表现层意思差不多,但请注意,表现层中的“Web服务”虽然是服务,但它是表现层的东西
从上图还可以看到,表现层与应用层之间是通过数据传输对象(DTO)进行交互的,它的目的只是为了对领域对象进行数据封装,实现层与层之间的数据传递。
因为领域对象更注重领域,而DTO更注重数据。不仅如此,由于“富领域模型”的特点,这样做会直接将领域对象的行为暴露给表现层。
文章引用:/article/4757554.html
相关文章推荐
- 领域驱动设计-学习笔记 分层架构
- IDDD 实现领域驱动设计-架构之经典分层
- 领域驱动设计中面向经典分层架构的领域事件的设计与实现
- 领域驱动设计(一)理解分层架构
- 领域驱动设计中面向经典分层架构的领域事件的设计与实现
- 领域驱动设计-学习笔记 分层架构
- 领域驱动设计的标准分层架构
- 领域驱动设计整理——概念&架构
- 结合领域驱动设计的SOA分布式软件架构 (转)
- 结合领域驱动设计的SOA分布式软件架构
- IDDD 实现领域驱动设计-SOA、REST 和六边形架构
- 【转载】实体框架之领域驱动实践:分层架构
- 【架构设计 领域驱动开发 三】战略建模
- 【tornado】系列项目(一)之基于领域驱动模型架构设计的京东用户管理后台
- 领域驱动设计:理念,架构和若干重要细节(draft)
- 领域驱动设计(Domain Driven Design)参考架构详解
- ddd(领域驱动设计)之架构总结
- 架构设计-DDD领域驱动设计模式
- Evans DDD(领域驱动开发) 与架构分层
- 结合领域驱动设计的SOA分布式软件架构