EBI、DDD及其演变架构史

一、背景

      “领域驱动架构”,大多能聊到DDD(Domain-Driven Design),实际上早期思想EBI架构 1992年就诞生了。核心价值点在于:关注核心业务领域(高内聚),分离实现层(低耦合)。后续一些演变架构有:端口和适配器架构、洋葱架构、整洁架构、事件驱动架构。这一系列的架构演变

 二、架构演变

          EBI 架构(Entity-Boundary-Interactor,实体-边界-交互器)是Ivar Jacobson 在 1992 年就在他的著作 Object-Oriented Software Engineering: A use case driven approach中提出的

          Jacobson 把它叫做实体-接口-控制(Entity-Interface-Control),但是后来改成了 EBI,避免“接口”和编程语言中的结构“接口”混淆,以及“控制”和 MVC 中的“控制器”混淆。如下图所示:

EBI、DDD及其演变架构史_第1张图片

 上图是UML!Ivar Jacobson就是UML的三大创始人之一

核心

  • Entity实体:实体对象承载着相关业务领域的数据和操作。对应着MVC的Model层。
  • Boundary边界:边界对象是对系统接口的建模。所有依赖系统环境(工具和传达机制)的功能都属于边界对象。对应着 MVC 中的 View 和 Controller 的整个展现层。
  • Interactor交互器:代表了展现层和实体之间的连接,也就是应用服务(编排用例)和领域服务(DDD概念)。

优点

  • 通过职责的封装将系统的变化控制在局部(最好是一个对象)。(单一职责原则

2.2 DDD领域驱动设计(2003)

Eric Evans 于 2003 年出版了《领域驱动设计:软件核心复杂性应对之道》,在书中他创造了领域驱动设计方法。是“领域驱动“领域的指明灯。DDD把实现分为4个大层次,如下图

EBI、DDD及其演变架构史_第2张图片

 

分层:

  • 1.User Interface用户界面层:负责绘制和应用交互的屏幕界面并将输入翻译成应用的命令。它们和EBI架构中的Boundary边界对象对应。
  • 2.Application应用服务层:协调领域对象完成用例。它不包含业务逻辑。应用层和EBI架构中的Interactor交互器相对应,只有一点不同,交互器是和界面或实体无关的任意对象,而这里应用层只包含和用例相关的对象。
  • 3.Domain领域层:这个层次包含了所有的业务逻辑,如领域服务、实体、事件和其他包含业务逻辑的任意对象类型。它和 EBI 架构中的Entity实体对象类型对应。
  • 4.Infrastructure基础设施层:支持上述三个层次的技术能力,例如,持久化或者消息机制。

核心

  领域模型准确反映了业务语言,而传统数据对象除了简单setter/getter方法外,没有任何业务方法,即失血模型,那么DDD领域模型就是充血模型(业务方法定义在实体对象中)

优点

  • 首次清晰描述了领域驱动的分层实现并统一了业务语言。
  • 单一职责、低耦合、高内聚、业务内核沉淀。

2.3 端口和适配器架构(2005)

2005年,Alistair Cockburn构思了端口和适配器架构 (又称六边形架构)并记录在他的博客中。下面这句话就是他对该架构的目标的定义:

让用户、程序、自动化测试和批处理脚本可以平等地驱动应用,让应用的开发和测试可以独立于其最终运行的设备和数据库。——Alistair Cockburn 2005,端口和适配器     如下图所示:

EBI、DDD及其演变架构史_第3张图片

 

核心

  1. 左侧: 代表 UI 的适配器被称为主适配器,它们发起了对应用的一些操作,端口(应用层API)和它的具体实现(controller实现)都在应用内部
  2. 右侧: 表示和后端工具链接的适配器,被称为从适配器,它们只会对主适配器的操作作出响应,端口在应用内部(业务接口),具体实现(impl)在应用之外

优点

  1. 业务应用和实现(技术)隔离。(面向接口编程)

  2. 方便测试。(基于接口)

2.4 扩散领域架构(2008)

2008 年 Jeffrey Palermo 提出了扩散领域架构。在我看来,它在端口和适配器架构的基础上贯彻了将领域放在应用中心,将传达机制(UI)和系统使用的基础设施(ORM、搜索引擎、第三方 API...)放在外围的思路。

架构在业务逻辑加入了一些在“领域驱动设计”中被识别出来的层次。如下图:

EBI、DDD及其演变架构史_第4张图片

核心

  • 围绕独立的对象模型构建应用。
  • 内层定义接口,外层实现接口。
  • 依赖的方向指向圆心。
  • 所有的应用代码可以独立于基础设施编译和运行。

优点

  • 职责分离更彻底,高内聚低耦合。
  • 更好的可测试性和可维护性。

2.5 整洁架构(2012)

Robert C. Martin(Uncle Bob)于2012年发表了整洁架构。这套架构是站在巨人的肩膀上,把MVC、EBI、端口适配器、洋葱架构、DDD融会贯通,形成了一套落地实践方案

EBI、DDD及其演变架构史_第5张图片

 

四层模型

  • Enterprise Business Rules  企业级业务规则层:核心业务内聚(对应DDD的领域服务+领域实体)。
  • Application Business Rules 应用级业务规则层:应用层业务编排。
  • Interface Adapters              接口适配层:数据转化。
  • Frameworks & Drivers        框架和驱动层:底层实现和数据库等驱动。

Robert C. Martin有一份落地细节图,如下:

EBI、DDD及其演变架构史_第6张图片

核心

  • 前端(左边)就是MVPVM架构(MVC的一种最贴合现代的延伸架构)
  • 后端(右边)是EBI架构(Entity-Boundary-Interactor)

优点

  • 它告诉我们如何把所有的概念、规则和模式整合起来,形成一种标准实现套路。

三、总结

纵观EBI架构、DDD领域驱动设计、端口适配器架构、洋葱架构、整洁架构。完全没有冲突,就是领域设计的完美落地历史。一张图归纳之

EBI、DDD及其演变架构史_第7张图片

 

参考:

DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together – @hgraca

2008 – Jeffrey Palermo – The Onion Architecture: part 1

2008 – Jeffrey Palermo – The Onion Architecture: part 2

2008 – Jeffrey Palermo – The Onion Architecture: part 3

2013 – Jeffrey Palermo – The Onion Architecture: part 4 – After Four Years

Clean Coder Blog

17.清晰架构(01): 融合 DDD、洋葱架构、整洁架构、CQRS...(译) - 简书

 

 

你可能感兴趣的:(架构,驱动设计,EBI架构,DDD领域)