知道分层架构
分层架构是运用最为广泛的架构形式，简直每个软件体系都需求经过层（Layer）来阻隔不同的关注点（Concern Point），以此应对不同需求的改变，使得这种改变能够独立进行；此外，分层架构形式仍是阻隔事务复杂度与技能复杂度的利器，《范畴驱动规划形式、原理与实践》写道：
为了防止将代码库变成大泥球（BBoM）并因而削弱范畴模型的完好性且终究削弱可用性，体系架构要支撑技能复杂性与范畴复杂性的别离。引起技能完成产生改变的原因与引起范畴逻辑产生改变的原因明显不同，这就导致根底设施和范畴逻辑问题会以不同速率产生改变。
这儿所谓的“以不同速率产生改变”，其实便是引起改变的原因各有不同，这正好是单一责任准则（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），便是为了给调用者供给完好的事务用例。
分层的第二个依据是面临改变。分层时应针对不同的改变原因确认层次的鸿沟，禁止层次之间相互搅扰，或许至少将改变对各层带来的影响降到最低。例如数据库结构的修正天然会影响到根底设施层的数据模型以及范畴层的范畴模型，但当咱们仅需求修正根底设施层中数据库拜访的完成逻辑时，就不应该影响到范畴层了。层与层之间的联系应该是正交的。所谓“正交”，并非二者之间没有联系，而是笔直相交的两条直线。仅有相关的依靠点是这两条直线的相交点，即两层之间的协作点。正交的两条直线，不管哪条直线进行延伸，都不会对另一条直线产生任何影响（指直线的投影）。假如非正交，即“斜交”，当一条直线延伸时，它总是会投影到另一条直线，这就意味着另一条直线会遭到它改变的影响。
在进行分层时，咱们还应该确保同一层的组件处于同一个笼统层次。这是分层架构的规划准则，它学习了 Kent Beck 在 Smalltalk Best PracTIce Patterns 一书提出的“组合办法”形式。该形式要求一个办法中的一切操作处于相同的笼统层，这便是所谓的“单一笼统层次准则（SLAP）”。这一准则能够运用到分层架构中。例如在一个依据元数据的多租户报表体系中，咱们特别界说了一个引擎层（engine layer），这是一个隐喻，相当于为报表体系供给报表、实体与数据的驱动引擎。引擎层之下，是根底设施层，供给了多租户、数据库拜访与元数据解析与办理等功用。在引擎层之上是一个操控层，经过该操控层的组件能够将引擎层的各个组件组合起来。分层架构的顶端是面向用户的用户展现层。如下图所示：
层之间的协作
在咱们固有的知道中，分层架构的依靠都是自顶向下传递的，这也契合大大都人对分层的认知模型。从笼统层次看，层次越处于下端，就会变得越通用越公共，与详细的事务阻隔得越远。出于重用的考虑，这些通用和公共的功用往往会被独自剥离出来构成渠道或结构，在体系鸿沟内的低层，除了面向高层供给满意的完成外，就都成了渠道或结构的调用者。换言之，越是通用的层，越有或许与外部渠道或结构构成强依靠。若依靠的传递方向依然选用自顶向下，就会导致体系的事务目标也随之依靠于外部渠道或结构。
依靠倒置准则（Dependency Inversion Principle，DIP）提出了对这种自顶向下依靠的应战，它要求“高层模块不应该依靠于低层模块，二者都应该依靠于笼统。”这个准则拨乱反正，给了咱们当头棒喝——谁规定在分层架构中，依靠就一定要沿着自顶向下的方向传递？咱们常常了解依靠，是由于被依靠方需求为依靠方（调用方）供给功用支撑，这是从功用重用的视点来考虑的。但咱们不能疏忽改变对体系产生的影响！与制作房子相同，咱们天然期望分层的模块“构建”在安稳的模块之上。谁更安稳？笼统更安稳。因而，依靠倒置准则隐含的实质是：咱们要依靠不变或安稳的元素（类、模块或层）。也便是该准则的第二句话：笼统不应该依靠于细节，细节应该依靠于笼统。
这一准则实践是“面向接口规划”准则的表现，即“针对接口编程，而不是针对完成编程”。高层模块对低层模块的完成是一窍不通的，带来的优点是：
低层模块的细节完成能够独立改变，防止改变对高层模块产生污染
在编译时，高层模块能够独立于低层模块独自存在
关于高层模块而言，低层模块的完成是可替换的
假使高层依靠于低层的笼统，必定会面临一个问题：如何将详细的完成传递给高层的类？由于在高层经过接口阻隔了对详细完成的依靠，就意味着这个详细依靠被搬运到了外部，终究运用哪一种详细完成，由外部的调用者来决议。只要在运转调用者代码时，才将外面的依靠传递给高层的类。MarTIn Fowler 形象地将这种机制称为“依靠注入（dependency injection）”。
为了更好地免除高层对低层的依靠，咱们往往需求将依靠倒置准则与依靠注入结合起来。
层之间的协作并不一定是自顶向下的传递通讯，也有或许是自底向上通讯，例如在 CIMS（计算机集成制作体系）中，往往会由低层的设备监测体系监测（侦听）设备状况的改变。当状况产生改变时，需求将改变的状况告知到上层的事务体系。假如说自顶向下的音讯传递往往被描绘为“恳求（或调用）”，则自底向上的音讯传递则往往被形象地称之为“告知”。假使咱们倒置一下方向，天然也能够视为这是上层对基层的调查，故而能够运用调查者形式（Observer Pattern），在上层界说 Observer 接口，并供给 update（） 办法供基层在感知状况产生改变时调用。或许，咱们也能够以为这是一种回调机制。尽管实质上这并非回调，但规划原理是相同的。
假如选用了调查者形式，则与前面叙述的依靠倒置准则有差相好像之意，由于基层为了告知上层，需求调用上层供给的 Observer 接口。如此看来，不管是上层对基层的“恳求（或调用）”，抑或基层对上层的“告知”，都推翻了咱们固有思维中那种高层依靠低层的了解。
现在，咱们对分层架构有了更清醒的知道。咱们必需求打破那种谈分层架构必为经典三层架构又或范畴驱动规划引荐的四层架构这种固有思维，而是将分层视为关注点别离的水平笼统层次的表现。已然如此，架构的笼统层数就不是固定的，乃至每一层的称号也未必遵从固有（经典）的分层架构要求。规划体系的层需得结合该体系的详细事务场景而定。当然，咱们也要知道到层次多少的利害：过多的层会引进太多的直接而添加不用要的开支，层太少又或许导致关注点不行别离，导致体系的结构不合理。
咱们还需求正视架构中各层之间的协作联系，打破高层依靠低层的固有思维，从免除耦合（或下降耦合）的视点探究层之间或许的协作联系。别的，咱们还需求确认分层的架构准则（或束缚），例如是否答应跨层调用，即每一层都能够运用比它低的一切层的服务，而不只是是相邻低层。这便是所谓的“松懈分层体系（Relaxed Layered System）”。
该怎样演进范畴驱动架构？
咱们在上文中回忆了经典三层架构与范畴驱动规划四层架构，但是任何技能定论都并非句点，而只是代表了满意其时技能布景的一种判别，技能总是在演进，范畴驱动架构亦是如此。与其关怀成果，不如将眼睛投往这个演进的进程，或许景色会愈加动听。
依据“依靠倒置准则”与 Robert Martin 提出的“整齐架构”思维，咱们推翻了Eric Evans 在《范畴驱动规划》书中提出的分层架构。Vaughn Vernon 在《完成范畴驱动规划》一书中给出了改善版的分层架构，他将根底设施层古怪地放在了整个架构的最上面：
整个架构模型明晰地表达了范畴层别无依靠的特质，但整个架构却简单给人以一种紊乱感。单以这个分层模型来看，虽则没有让高层依靠低层，却又反过来让低层依靠了高层，这依然是不合理的。当然你能够说此刻的根底设施层现已变成了高层，但是从之前剖析的南向网关与北向网关来说，根底设施层存在被“肢解”的或许。坦白讲，这个架构模型依然没有处理人们对分层架构的认知过错，例如它并没有很好地表达依靠倒置准则与依靠注入。还需求注意的是，这个架构模型将根底设施层放在了整个分层架构的最顶端，导致它依靠了用户界面层，这好像并不能无懈可击。咱们需求从头整理范畴驱动架构，展现它的演进进程。
层之间的协作
在咱们固有的知道中，分层架构的依靠都是自顶向下传递的，这也契合大大都人对分层的认知模型。从笼统层次看，层次越处于下端，就会变得越通用越公共，与详细的事务阻隔得越远。出于重用的考虑，这些通用和公共的功用往往会被独自剥离出来构成渠道或结构，在体系鸿沟内的低层，除了面向高层供给满意的完成外，就都成了渠道或结构的调用者。换言之，越是通用的层，越有或许与外部渠道或结构构成强依靠。若依靠的传递方向依然选用自顶向下，就会导致体系的事务目标也随之依靠于外部渠道或结构。
依靠倒置准则（Dependency Inversion Principle，DIP）提出了对这种自顶向下依靠的应战，它要求“高层模块不应该依靠于低层模块，二者都应该依靠于笼统。”这个准则拨乱反正，给了咱们当头棒喝——谁规定在分层架构中，依靠就一定要沿着自顶向下的方向传递？咱们常常了解依靠，是由于被依靠方需求为依靠方（调用方）供给功用支撑，这是从功用重用的视点来考虑的。但咱们不能疏忽改变对体系产生的影响！与制作房子相同，咱们天然期望分层的模块“构建”在安稳的模块之上。谁更安稳？笼统更安稳。因而，依靠倒置准则隐含的实质是：咱们要依靠不变或安稳的元素（类、模块或层）。也便是该准则的第二句话：笼统不应该依靠于细节，细节应该依靠于笼统。
这一准则实践是“面向接口规划”准则的表现，即“针对接口编程，而不是针对完成编程”。高层模块对低层模块的完成是一窍不通的，带来的优点是：
低层模块的细节完成能够独立改变，防止改变对高层模块产生污染
在编译时，高层模块能够独立于低层模块独自存在
关于高层模块而言，低层模块的完成是可替换的
假使高层依靠于低层的笼统，必定会面临一个问题：如何将详细的完成传递给高层的类？由于在高层经过接口阻隔了对详细完成的依靠，就意味着这个详细依靠被搬运到了外部，终究运用哪一种详细完成，由外部的调用者来决议。只要在运转调用者代码时，才将外面的依靠传递给高层的类。Martin Fowler 形象地将这种机制称为“依靠注入（dependency injection）”。
为了更好地免除高层对低层的依靠，咱们往往需求将依靠倒置准则与依靠注入结合起来。
层之间的协作并不一定是自顶向下的传递通讯，也有或许是自底向上通讯，例如在 CIMS（计算机集成制作体系）中，往往会由低层的设备监测体系监测（侦听）设备状况的改变。当状况产生改变时，需求将改变的状况告知到上层的事务体系。假如说自顶向下的音讯传递往往被描绘为“恳求（或调用）”，则自底向上的音讯传递则往往被形象地称之为“告知”。假使咱们倒置一下方向，天然也能够视为这是上层对基层的调查，故而能够运用调查者形式（Observer Pattern），在上层界说 Observer 接口，并供给 update() 办法供基层在感知状况产生改变时调用。或许，咱们也能够以为这是一种回调机制。尽管实质上这并非回调，但规划原理是相同的。
假如选用了调查者形式，则与前面叙述的依靠倒置准则有差相好像之意，由于基层为了告知上层，需求调用上层供给的 Observer 接口。如此看来，不管是上层对基层的“恳求（或调用）”，抑或基层对上层的“告知”，都推翻了咱们固有思维中那种高层依靠低层的了解。
现在，咱们对分层架构有了更清醒的知道。咱们必需求打破那种谈分层架构必为经典三层架构又或范畴驱动规划引荐的四层架构这种固有思维，而是将分层视为关注点别离的水平笼统层次的表现。已然如此，架构的笼统层数就不是固定的，乃至每一层的称号也未必遵从固有（经典）的分层架构要求。规划体系的层需得结合该体系的详细事务场景而定。当然，咱们也要知道到层次多少的利害：过多的层会引进太多的直接而添加不用要的开支，层太少又或许导致关注点不行别离，导致体系的结构不合理。
咱们还需求正视架构中各层之间的协作联系，打破高层依靠低层的固有思维，从免除耦合（或下降耦合）的视点探究层之间或许的协作联系。别的，咱们还需求确认分层的架构准则（或束缚），例如是否答应跨层调用，即每一层都能够运用比它低的一切层的服务，而不只是是相邻低层。这便是所谓的“松懈分层体系（Relaxed Layered System）”。
该怎样演进范畴驱动架构？
咱们在上文中回忆了经典三层架构与范畴驱动规划四层架构，但是任何技能定论都并非句点，而只是代表了满意其时技能布景的一种判别，技能总是在演进，范畴驱动架构亦是如此。与其关怀成果，不如将眼睛投往这个演进的进程，或许景色会愈加动听。
依据“依靠倒置准则”与 Robert Martin 提出的“整齐架构”思维，咱们推翻了Eric Evans 在《范畴驱动规划》书中提出的分层架构。Vaughn Vernon 在《完成范畴驱动规划》一书中给出了改善版的分层架构，他将根底设施层古怪地放在了整个架构的最上面：
