领域驱动分层架构.docxVIP

领域驱动-分层架构 2021-07-30 生疏分层架构 分层架构是运用最为广泛的架构模式，几乎每个软件系统都需要通过层（Layer）来隔离不同的关注点（Concern Point），以此应对不同需求的变化，使得这种变化可以独立进行；此外，分层架构模式还是隔离业务简单度与技术简单度的利器，《领域驱动设计模式、原理与实践》写道： 这里所谓的“以不同速率发生变化”，其实就是引起变化的缘由各有不同，这正好是单一职责准绳（Single-Responsibility Principle，SRP）的体现。Robert Martin 认为单一职责准绳就是“一个类应当只要一个引起它变化的缘由”，换言之，假如有两个引起类变化的缘由，就需要分别。单一职责准绳可以理解为架构准绳，这时要考虑的就不是类，而是层次。我们为什么要将业务与基础设备分开？正是由于引起它们变化的缘由不同。 经典分层架构 分层架构由来已久，将一个软件系统进行分层，好像已经成为了每个开发人员的固无意识，甚至不必思考即可自然得出。这其中最为经典的就是三层架构以及领域驱动设计提出的四层架构。 经典三层架构 在软件架构中，经典三层架构自顶向下由用户界面层（User Interface Layer）、业务规律层（Business Logic Layer）与数据访问层（Data Access Layer）组成。该分层架构之所以能够流行，是有其历史缘由的。在提出该分层架构的时代，多数企业系统往往较为简约，本质上都是一个单体架构（Monolithic Architecture）的数据库管理系统。这种分层架构已经是Client-Server架构的进化了，它有效地隔离了业务规律与数据访问规律，使得这两个不同关注点能够相对自在和独立地演化。一个经典的三层架构如下所示：? 领域驱动设计的经典分层架构 领域驱动设计在经典三层架构的基础上做了进一步改良，在用户界面层与业务规律层之间引入了新的一层，即应用层（Application Layer）。同时，一些层次的命名也发生了变化。将业务规律层更名为领域层自然是题中应有之义，而将数据访问层更名为基础设备层（Infrastructure Layer），则突破了之前数据库管理系统的限制，扩大了这个担任封装技术简单度的基础层次的内涵。下图为 Eric Evans 在其经典著作《领域驱动设计》中的分层架构： 追溯分层架构的本源 当分层架构变得越来越普准时，我们的设计反而变得越来越僵化。一部分软件设计师并未理解分层架构的本质，只晓得依样画葫芦地将分层应用到系统中。要么接受经典的三层架构，要么遵照领域驱动设计改进的四层架构，却未思考和叩问如此分层到底有何道理？这是分层架构被滥用的根源。 视分层（Layer）为一个固有的架构模式，其滥觞应为 Frank Buschmann 等人著的《面对模式的软件架构》第一卷《模式系统》。该模式参考了 ISO 对 TCP/IP 协议的分层。《模式系统》对分层的描述为： 分层架构模式有助于构建这样的应用：它能被分解成子任务组，其中每个子任务组处于一个特定的笼统层次上。 明显，这里所谓的“分层”首先是一个规律的分层，对子任务组的分解需要考虑笼统层次，一种水平的笼统层次。既然为水平的分层，必定存在层的高与低；而笼统层次的不同，又打算了分层的数量。因而，对于分层架构，我们需要处理如下问题： 分层的依据与准绳是什么？ 层与层之间是怎样协作的？ 分层的依据与准绳 我们之所以要以水平方式对整个系统进行分层，是我们下意识地确定了一个认知规章：机器为本，用户至上。机器是运转系统的基础，而我们打造的系统却是为用户供应服务的。分层架构中的层次越往上，其笼统层次就越面对业务，面对用户；分层架构中的层次越往下，其笼统层次就变得越通用，面对设备。为什么经典分层架构为三层架构？正是源于这样的认知规章：其上，面对用户的体验与交互；其中，面对应用与业务规律；其下，面对各种外部资源与设备。在进行分层架构设计时，我们完全可以基于这个经典的三层架构，沿着水平方向进一步切分属于不同笼统层次的关注点。因而，分层的第一个依据是基于关注点为不同的调用目的划分层次。以领域驱动设计的四层架构为例，之所以引入应用层（Application Layer），就是为了给调用者供应完整的业务用例。 分层的其次个依据是面对变化。分层时应针对不同的变化缘由确定层次的边界，严禁层次之间相互干扰，或者至少将变化对各层带来的影响降到最低。例如数据库结构的修改自然会影响到基础设备层的数据模型以及领域层的领域模型，但当我们仅需要修改基础设备层中数据库访问的实现规律时，就不应当影响到领域层了。层与层之间的关系应当是正交的。所谓“正交”，并非二者之间没有关系，而是垂直相交的两条直线。独一相关的依靠点是这两条直