前语
了解明晰架构之前需求咱们先了解以下常见架构计划：
EBI架构(Entity-Boundary-Interactor Architecture)
范畴驱动规划(Domain-Driven Design)
端口与适配器架构(Ports & Adapters Architecture,又称为六边形架构)
洋葱架构(Onion Architecture)
整洁架构(Clean Architecture)
作业驱动架构(Event-Driven Architecture)
指令查询职责别离形式(CQRS，即Command Query Responsibility Segregation)
面向服务的架构(Service Oriented Architecture)
明晰架构（Explicit Architecture，直译为显式架构）是将上述架构的部分优势整合之后发生的另一种架构，因其2017年现已出现，现已不算是一种新的架构，实践运用的项目尚且较少。以下首要介绍架构的构成及各步骤的意义。
1 架构演化进程
1.1 体系的根本构建块
端口和适配器架构明晰地辨认出了一个体系中的三个根本代码构建块：
- 运转用户界面所需的构建块；
- 体系的事务逻辑，或许运用中心；
- 基础设施代码。
1.2 东西
在远离【运用中心】的地方，有一些运用会用到的东西，例如数据库引擎、搜索引擎、Web 服务器或许指令行操控台(虽然最终两种东西也是传达机制)。
把指令行操控台和数据库引擎都是运用运用的东西，要害的区别在于，指令行操控台和 Web 服务器奉告咱们的运用它要做什么，而数据库引擎是由咱们的运用来奉告它做什么。
1.3 将传达机制和东西衔接到运用中心
衔接东西和运用中心的代码单元被称为适配器(源自端口和适配器架构)。适配器有效地完结了让事务逻辑和特定东西之间能够彼此通讯的代码。
“奉告咱们的运用应该做什么”的适配器被称为主适配器或主动适配器，而那些“由咱们的运用奉告它该做什么”的适配器被称为从适配器或许被迫适配器。
1.3.1 端口
适配器需求依照运用中心某个特定的入口的要求来创立，即端口。在大多数言语里最简略的形式便是接口，但实践上也或许由多个接口和 DTO 组成。
端口(接口)坐落事务逻辑内部，而适配器坐落其外部，这一点要特别注意。要让这种形式依照设想发挥效果，端口依照运用中心的需求来规划而不是简略地套用东西的 API。
1.3.2 主适配器或主动适配器
主适配器或主动适配器包装端口并经过它奉告运用中心应该做什么。它们将来自传达机制的信息转化成对运用中心的办法调用。
换句话说，咱们的主动适配器便是 Controller 或许操控台指令，它们需求的接口(端口)由其他类完结，这些类的方针经过结构办法注入到 Controller 或许操控台指令。
再举一个更详细的比方，端口便是 Controller 需求的 Service 接口或许 Repository 接口。Service、Repository 或 Query 的详细完结被注入到 Controller 供 Controller 运用。
此外，端口还能够是指令总线接口或许查询总线接口。这种状况下，指令总线或许查询总线的详细完结将被注入到 Controller 中， Controller 将创立指令或查询并传递给相应的总线。
1.3.3 从适配器或被迫适配器
和主动适配器包装端口不同，被迫适配器完结一个端口(接口)并被注入到需求这个端口的运用中心里。
举个比方，假设有一个需求存储数据的简略运用。咱们创立了一个符合运用要求的耐久化接口，这个接口有一个保存数据数组的办法和一个依据 ID 从表中删去一行的办法。接口创立好之后，不管何时运用需求保存或删去数据，都应该运用完结了这个耐久化接口的方针，而这个方针是经过结构办法注入的。
现在咱们创立了一个专门针对 MySQL 完结了该接口的适配器。它具有保存数组和删去表中一行数据的办法，然后在需求运用耐久化接口的地方注入它。
假如未来咱们决议更换数据库供应商，比方换成 PostgreSQL 或许 MongoDB，咱们只用创立一个专门针对 PostgreSQL 完结了该接口的适配器，在注入时用新适配器替代旧适配器。
1.3.4 操控回转
这种形式有一个特征，适配器依靠特定的东西和特定的端口(它需求供给接口的特定完结)。但事务逻辑只依靠依照它的需求规划的端口(接口)，它并不依靠特定的适配器或东西。
换句话说，适配器依据运用的东西不同能够灵敏改变，可是事务逻辑发生的接口根本不会改变。
这意味着依靠的方向是由外向内的，这便是架构层面的操控回转准则。
再一次强调，端口依照运用中心的需求来规划而不是简略地套用东西的 API。
1.4 运用中心的结构
洋葱架构选用了 DDD 的分层，将这些分层融合进了端口和适配器架构。这种分层为坐落端口和适配器架构“六边形”内的事务逻辑带来一种结构安排，和端口与适配器架构一样，依靠的方向也是由外向内。
1.4.1 运用层
在运用中，由一个或多个用户界面触发的运用中心中的进程便是用例。例如，在一个 CMS 体系中，咱们能够供给普通用户运用的运用 UI、CMS 管理员运用的独立的 UI、指令行 UI 以及 Web API。这些 UI(运用)能够触发的用例或许是专门为它规划的，也能够是多个 UI 复用的。
用例界说在运用层中，这是 DDD 供给的榜首个被洋葱架构运用的层。
这个层包含了运用服务(以及它们的接口)，也包含了端口与适配器架构中的接口，例如 ORM 接口、搜索引擎接口、消息接口等等。假如咱们运用了指令总线和查询总线，指令和查询别离对应的处理程序也归于这一层。
1.4.2 范畴层
持续向内一层便是范畴层。这一层中的方针包含了数据和操作数据的逻辑，它们只和范畴自身有关，独立于调用这些逻辑的事务进程。它们彻底独立，对运用层彻底无感知。
1.范畴服务
咱们偶尔会碰到某种触及不同实体的范畴逻辑，当然，不管实体是否相同，直觉奉告咱们这种范畴逻辑并不归于这些实体，这种逻辑不是这些实体的直接职责。
所以，咱们的榜首反应或许是把这些逻辑放到实体外的运用服务中，这意味着这些范畴逻辑就不能被其它的用例复用：范畴逻辑应该远离运用层。
解决办法是创立范畴服务，它的效果是接纳一组实体并对它们履行某种事务逻辑。范畴服务归于范畴层，因而它并不了解运用层中的类，比方运用服务或许 Repository。另一方面，它能够运用其他范畴服务，当然还能够运用范畴模型方针。
2.范畴模型
在架构的正中心，是彻底不依靠外部任何层次的范畴模型。它包含了那些表明范畴中某个概念的事务方针。这些方针的比方首要便是实体，还有值方针、枚举以及其它范畴模型中用到的任何方针。
范畴作业也“活在”范畴模型中。当一组特定的数据发生改变时就会触发这些作业，而这些作业会带着这些改变的信息。换句话说，当实体改变时，就会触发一个范畴作业，它带着着发生改变的特点的新值。这些作业能够完美地运用于作业溯源。
1.5 组件
目前为止，咱们都是运用层次来区别代码，但这是细粒度的代码阻隔。依据 Robert C. Martin 在尖叫架构中表达的观念，依照子域和限界上下文对代码进行区别这种粗粒度的代码阻隔相同重要。这一般被叫做“按特性分包”或许“按组件分包”，和“按层次分包”相照应。
我是“按组件分包”办法的坚定拥护者，在此我厚着脸皮将 Simon Brown 按组件分包的示意图做了如下修正：
这些代码块在前面描绘的分层基础上再进行了“横切”，它们是运用的组件(译)。
组件的比方包含认证、授权、账单、用户、评论或帐号，而它们总是都和范畴相关。像认证和授权这样的限界上下文应该被看作外部东西，咱们应该为它们创立适配器，把它们隐藏在某个端口之后。
1.5.1 组件解耦
与细粒度的代码单元(类、接口、特质、混合等等)一样，粗粒度的代码单元(组件)也会从高内聚低耦合中获益。
咱们运用依靠注入（经过将依靠注入类而不是在类内部初始化依靠）以及依靠倒置（让类依靠笼统，即接口和笼统类，而不是详细类）来解耦类。这意味着类不用知道它要运用的详细类的任何信息，不用引证所依靠的类的彻底限定类名。
以相同的办法彻底解耦组件意味着组件不会直接了解其它任何组件的信息。换句话说，它不会引证任何来自其它组件的细粒度的代码单元，乃至都不会引证接口！这意味着依靠注入和依靠倒置对组件解耦是不够用的，咱们还需求一些架构层级的结构。咱们需求作业、同享内核、终究共同性乃至发现服务！
1.触发其它组件的逻辑
当一个组件(组件 A)中有作业发生需求另一个组件(组件B)做些什么时，咱们不能简略地从组件 A 直接调用组件 B 中的类/办法，因为这样 A 就和 B 耦合在一同了。
可是咱们能够让 A 运用作业派发器，派发一个范畴作业，这个作业将会投递给任何监听它的组件，例如 B，然后 B 的作业监听器会触发期望的操作。这意味着组件 A 将依靠作业派发器，但和 B 解耦了。
可是，假如作业自身“活在” A 中，这将意味着 B 知道了 A 的存在，就和 A 存在耦合。要去掉这个依靠，咱们能够创立一个包含运用中心功用的库，由一切组件同享，这便是同享内核。这意味着两个组件都依靠同享内核，而它们之间却没有耦合。同享内核包含了运用作业和范畴作业这样的功用，并且还包含标准方针，以及其它任何有理由同享的东西。记住同享内核的规模应该尽或许的小，因为它的任何改变都会影响一切运用组件。
并且，假如咱们的体系是言语异构的，比方运用不同言语编写的微服务生态，同享内核需求做到与言语无关的，这样它才干被一切组件了解，不管它们是用哪种言语编写的。例如，同享内核应该包含像 JSON 这样无关言语的作业描绘(例如，称号、特点，或许还有办法，虽然它们对标准方针来说更有意义)而不是作业类，这样一切组件或许微服务都能够解析它，还能够主动生成各自的详细完结。
这种办法既适用于单体运用，也适用于像微服务生态体系这样的分布式运用。可是，这种办法只适用于作业异步投递的状况，在需求即时完结触发其它组件逻辑的上下文中并不适用！组件 A 将需求向组件 B 建议直接的调用，例如HTTP。这种状况下，要解耦组件，咱们需求一个发现服务，A 能够询问它得知恳求应该发送到哪里才干触发期望的操作，又或是向发现服务建议恳求并由发现服务将恳求代理给相关服务并终究回来响应给恳求方。这种办法会把组件和发现服务耦合在一同，但会让组件之间解耦。例如jsf。
2.从其它组件获得数据
准则上，组件不允许修正不“归于”它的数据，但能够查询和运用任何数据。
1）组件之间同享数据存储
当一个组件需求运用归于其它组件的数据时，比方说账单组件需求运用归于账户组件的客户姓名，账单组件会包含一个查询方针，能够在数据存储中查询该数据。简略的说便是账单组件知道任何数据集，但它只能经过查询只读地运用不“归于”它的数据。
2）按组件阻隔的数据存储
这种状况下，这种形式相同有效，但数据存储层面的杂乱度更高。
组件具有各自的数据存储意味着每个数据存储都包含：
- 一组归于它的数据，并且只允许它自己修正这些数据，让它成为单一现实来源；
- 一组其它组件数据的副本，它自己不能修正这些数据，但组件的功用需求这些数据，并且一旦数据在其所属的组件中发生了改变，这些副本需求更新。
每个组件都会创立其所需的其它组件数据的本地副本，在必要时运用。当数据在其所属的组件中发生了改变，该组件将触发一个带着数据改变的范畴作业。具有这些数据副本的组件将监听这个范畴作业并相应地更新它们的本地副本。
1.6 操控流
如前所述，操控流明显从用户出发，进入运用中心，抵达基础设施东西，再回来运用中心并终究回来给用户。但这些类到底是是怎么合作的？哪些类依靠哪些类？咱们怎样把它们组合在一同？
1.6.1 没有指令/查询总线
假如没有指令总线，操控器要么依靠运用服务，要么依靠查询方针。
上图中咱们运用了运用服务接口，虽然咱们会质疑这并没有必要。因为运用服务是咱们运用代码的一部分，并且咱们不会想用别的一种完结来替换它，虽然咱们或许会彻底地重构它。
1.6.2 有指令/查询总线
假如咱们的运用运用了指令/查询总线，UML 图根本没有改变，唯一的区别是操控器现在会依靠总线、指令或查询。它将实例化指令或查询，将它们传递给总线。总线会找到适宜的处理程序接纳并处理指令。
在下图中，指令处理程序接下来将运用运用服务。可是，这不总是有必要的，实践上大多数状况下，处理程序将包含用例的一切逻辑。只要在其它处理程序需求重用相同的逻辑时，咱们才需求把处理程序中的逻辑提取出来放到独自的运用服务中。
总线和指令查询，以及处理程序之间没有依靠。这是因为实践上它们之间应该相互无感知，才干供给满足的解耦。只要经过配置才干设置总线能够发现哪些指令，或许查询应该由哪个处理程序处理。
如你所见，两种状况下，一切跨越运用中心鸿沟的箭头——依靠——都指向内部。如前所述，这是端口和适配器架构、洋葱架构以及整洁架构的根本规则。
1.7 同享内核
同享内核由 DDD 之父 Eric Evans 界说，它是多个限界上下文之间同享的代码，由开发团队决议：
[…] 两个团队同意同享的范畴模型的子集。当然，和模型子集一同同享还包含代码的子集，还有和这部分模型有关的数据库规划。这部分明晰要同享的内容有着特别的状况，并且在没有和其他团队达到共同的状况下不应该修正。
Shared Kernel(ddd.fed.wiki.org/view/shared…), Ward Cunningham 的 DDD wiki
所以根本上，它或许是任何类型的代码：范畴层代码、运用层代码、库，随意什么代码。
可是，在这份心智地图里，咱们将它作为一些特定类型的代码的子集。同享内核包含的是范畴层和运用层的代码，这些代码会在限界上下文之间同享，让这些上下文能够相互通讯。
这意味着，例如，一个或多个限界上下文触发的作业能够在其它的限界上下文里被监听到。需求和这些作业一同同享的还有它们用到的一切数据类型，例如：实体 ID、值方针、枚举，等等。作业不应该直接运用像实体这样的杂乱方针，因为将它们序列化到行列中或是从行列中反序列化时都会遇到一些问题，所以同享的代码不应该太广泛。
当然，假如咱们手中的是一个由不同言语开发的微服务组成的多言语体系，同享内核有必要是描绘性的言语，格局是 json、xml、yaml 或许其它，这样一切的微服务都能了解。
因而，同享内核就彻底和其余的代码以及组件彻底解耦了。这样很好，因为这意味着虽然组件耦合了同享内核，但组件之间不再耦合。同享代码能够被明晰地辨认出来，并轻松地提取到一个独立的库中。
假如咱们决议将一个限界上下文从单体中别离出来并提取成一个微服务，这也会很便利。我对同享代码了然于心，能够轻松地将同享内核提取到一个库中。而这个库即能够安装到单体中，也能够安装到微服务中。
2 用代码表现架构
2.1 两张脑图
榜首张脑图由一系列同心圆层级组成，它们终究依照事务维度的运用模块切分，构成组件。在这张图里，依靠的方向由外向内，意味着内层对外层可见，而外层对内层不可见。
第二张则是一组平面的层级，其中最上面的一层便是前面这张同心圆，下一层是组件之间同享的代码（同享内核），再下一层使是咱们自己对编程言语的扩展，最下面一层则是实践运用的编程言语。这儿的依靠方向是自上而下的。
2.2 表现架构的代码风格
运用表现架构的代码风格，意味着代码风格（编码标准、类/办法/变量命名约好、代码结构…）某种程度上能够和阅读代码的人交流范畴和架构的规划意图。要完结表现架构的代码风格，首要有两种思路。
“[…] 表现架构的代码风格能让你给代码的阅读者留下提示，协助他们正确地推断出规划意图。”
—George Fairbanks(links.jianshu.com/go?to=https…)
榜首种思路是经过代码制品的姓名（类、变量、模块…）来传达范畴和架构的含义。因而，假如一个类是处理收据（Invoice）实体的库房（Repository），咱们就应该将它命名成InvoiceRepository，从这个姓名咱们就能够看出，它处理的是收据范畴的概念，而它在架构中被作为一个库房。这能够协助咱们了解它应该放在哪个地方，何时运用它以及怎么运用它。可是，我以为代码库房中并不是每个代码制品都需求这样做，例如，我觉得不用为每个实体（Entity）都加上后缀Entity，这样做就有些弄巧成拙，徒增噪音。
“[…] 代码应该表现架构。换句话说，我一看到代码，就应该能够明晰区域分出各种组件[…]”
—Simon Brown(links.jianshu.com/go?to=http%…)
第二种思路是让代码库房中的顶级制品明晰区域分出各个子域，即范畴维度的模块，也便是组件。
榜首种思路应该很清楚，无需赘述。但第二种思路有点儿奇妙，咱们得深入探讨一下。
2.3 让架构明晰的展现出来
在我的榜首张图里，咱们现已看到，在最粗粒度的层级上，咱们只要三种不同用途的代码：
- 用户界面，这儿的代码便是为了适配某个用例的传达机制；
- 运用中心，这儿的代码便是用例和范畴逻辑；
- 基础设施，这儿的代码便是为了适配运用中心所需的东西/库。
因而，在源代码的根目录下咱们能够创立三个文件夹来表现这三类代码，一个文件夹对应一个类别的代码。这三个文件夹表明三个命名空间，稍后咱们乃至能够创立测验来断言中心对用户界面和基础设施可见，反过来却不可见，也便是说，咱们能够测验由外向内的依靠方向。
2.3.1 用户界面
一个 Web 企业运用一般具有多套 API，例如，一套给客户端运用的 REST API，还有一套给第三方运用运用的 web-hook， 事务还有一套需求保护的遗留 SOAP API，或许还有一套给全新移动运用运用的 GraphQL API…
这样的应该一般还有一些 CLI 指令，用于守时作业（Cron Job）或按需的保护操作。
当然，还有普通用户能够运用的网站自身，但或许还有另一个供运用管理员运用的网站。
这些全都是同一个运用的不同视图，全都是同一个运用的不同用户界面。
实践上咱们的运用或许具有多个用户界面，其中有些仍是供非人类用户（第三方运用）运用的。咱们经过文件/命名空间来区别并阻隔这些用户界面，来展现出这一点。
用户界面首要有三类：API、CLI 和网站。所以咱们在UserInterface根命名空间里为每个类别创立一个文件夹，将不同界面的类型明晰区域分开来。
下一步，假如有必要的话，咱们还能够持续深入每种类型的命名空间，再创立更细分类的用户界面的命名空间（CLI 或许不需求再细分了）。
2.3.2 基础设施
和用户界面一样，咱们的运用运用了多种东西（库和第三方运用），例如 ORM、消息行列、SMS 供给商。
此外，上述每一种东西都能够有不同的完结。例如，考虑一家公司事务扩张到另一个国家的状况，因为价格的要素，不同的国家最好选用不同的 SMS 供给商：咱们需求端口相同的适配器的不同完结，这样运用时能够相互替换。另一个比方是对数据库 Schema 进行重构或许切换数据库引擎，需求（或决议要）切换 ORM 时：咱们会在运用中注入两种 ORM 适配器。
因而，在Infrastructure命名空间来说，咱们先给每一种东西类型创立一个命名空间（ORM、MessageQueue、SmsClient），然后再每一种东西类型内部为每一种用到的供应商（Doctrine、Propel、MessageBird、Twilio…）的适配器在创立一个命名空间。
2.3.3 中心
在Core命名空间下，能够依照最粗粒度的层级区别出三类代码： 组件（Component）、同享内核（Shared Kernel） 和 端口（Port）。为这三个类别创立文件夹/命名空间。
1.组件
在 Component 命名空间下，咱们为每个组件创一个命名空间，然后在每个组件命名空间下，咱们再别离为运用（Application）层和范畴（Domain）层别离创立一个命名空间。 在 Application 和 Domain 命名空间下，咱们先将全部类放在一同，跟着类的数量不断增加，再来考虑必要的分组（我觉得一个文件夹下就放一个类有些矫枉过正，所以我宁愿在必要时再进行分组）。
这是咱们就要考虑是依照事务主题（收据、交易…）分组仍是依照技能效果（库房、服务、值方针…）分组，但我觉得不管怎样分组影响都不大，因为这现已是整个代码安排树的叶子节点了，假如需求，在整个安排结构的最底端进行调整也很简略，不会影响代码库房的其它部分。
2.端口
和 Infrastructure 命名空间一样，Port 命名空间里中心运用的每一种东西都有一个命名空间，中心经过这些代码才干运用底层的这些东西。
这些代码还会被适配器运用，它们的效果便是端口和真实东西之间的转化。这种形式简略得不能再简略了，端口便是一个接口，但许多时分它还需求值方针、DTO、服务、构建起、查询方针乃至是库房。
3.同享内核
咱们把在组件之间同享的代码放到 Shared Kernel 命名空间下。尝试了几种不同的同享内核内部结构之后，我无法找到一种适用于一切状况的结构。有些代码和Core\Component一样按组件区别很合理（例如 Entity ID 明显归于一个组件），有些代码这样区别却不适宜（例如，作业或许被多个组件触发或监听）。或许要结合运用两种区别的思路。
2.3.4 用户区里的编程言语扩展
最终，咱们还有一些自己对编程言语的扩展。这个系列中前面一篇文章现已讨论过，这些代码本能够放在编程言语中，却因为某些原因没有。比方，在 PHP 中咱们能够想到的是 DateTime 类，它根据 PHP 供给的类扩展，供给了一些额外的办法。另一个比方是 UUID 类，虽然 PHP 没有供给，可是这个类天然便是纯粹的、对范畴无感，因而能够在任意项目中运用，并且不依靠任何范畴。
这些代码用起来和编程言语自己的供给的功用没啥区别，因而咱们要彻底掌控这些代码。可是，这并不是意味着咱们不能运用第三方库。咱们能用并且应该用，只要合理，可是这些库应该用咱们自己的完结包装起来（这样的话咱们能够便利的切换背后的第三方库），而运用代码应该直接运用这些包装代码。终究，这些代码能够自成项目，运用自己的 CVS 库房，被多个项目运用。
3 经过文档描绘架构
咱们有哪些可供选择的文档东西来表达整个运用的构建块以及运用怎么作业？！
UML
4+1 架构视图模型
架构决议计划记载
C4 模型
依靠图
运用地图
3.1 C4 模型
C4 模型是 Simon Brown 创造的，是我目前看到的关于软件架构文档的最好思路。我会快速地用自己的言语来阐述首要的思路，但运用的仍是他的图例。
其思路是用四种不同粒度（或许“缩放”）层级来记载软件的架构：
榜首级：体系上下文图
第二级：容器图
第三级：组件图
第四级：代码图
3.1.1 榜首级：体系上下文图
这是最粗粒度的图。它的细节很少但其首要方针是描绘运用所在的上下文。因而，这幅图中只要一个方块代表整个运用，其它围绕着运用的方块代表了运用要进行交付的外部体系和用户。
3.1.2 第二级：容器图
现在，咱们将运用放大，也便是上一级图中的蓝色方块，在这一级它对应的是下图中的虚线框。
在这个粒度等级，咱们将看到运用得容器，一个容器便是一个运用中技能上独立的一小部分，例如一个移动 App，一个 API 或许一个数据库。它还描绘了运用运用的首要技能和容器之间的通讯办法。
3.1.3 第三级：组件图
组件图展现的是一个容器内的组件。在 C4 模型上下文里，每个组件便是运用的一个模块，不光是范畴维度的模块（如账单、用户…）还包含纯粹的功用模块（如 email、sms…）。因而这个层级的图向咱们展现了一个容器的首要齿轮和齿轮之间的啮合联系。
3.1.4 第四级：代码图
这是最细粒度的图，意图是描绘一个组件内部的代码结构。在这个层级，咱们运用的是表明类等级制品的 UML 图。
4 总结
明晰架构集百家之长，天然有许多优势：
- 从外向内，越向内越偏中心准则，中心准则相对稳定。中心准则便是惯例的范畴层，供给中心才干
- 外层根据中心准则适配不同的事务场景，拼装内层的才干。这儿的外层便是惯例的接口层到运用层，首要运用主动适配器形式，重点关注 BFF(BackendsForFrontends) 及对内层才干的聚合
- 内层不依靠外层，不受事务改变而改变。关注才干的扩展，完结中心策略完结
- 鸿沟明显，尤其是范畴层与运用层之间
- CQRS 机制，耦合度低，经过外层拼装内层才干动态适配事务改变，扩展性高
这仅仅一份攻略！运用才是你的疆域，现实状况和详细用例才是运用这些常识的地方，它们才干勾勒出实践架构的轮廓！
咱们需求了解一切这些形式，但咱们还时常需求思考和了解咱们的运用需求什么，咱们应该在追求解耦和内聚的道路上走多远。这个决议或许受到许多要素的影响，包含项意图功用需求，也包含构建运用的时间期限，运用寿数，开发团队的体验等等要素。
运用遵从某种范畴结构组成，也遵从某种技能结构（即架构）组成。这两种结构才是一个运用的异乎寻常之处，而不是它运用的东西、库或许传达机制。假如咱们想让一个运用能够长期的保护，这两种结构都要明晰的表现在代码库房中，这样开发者才干知道、了解、遵从，并在需求时改善。
这种明晰度让咱们能够在编码的同时了解鸿沟，这能反过来协助咱们保持运用的模块化规划，做到高内聚低耦合。
附录：
- 软件架构编年史(译):www.jianshu.com/p/b477b2cc6…
- The Software Architecture Chronicles:herbertograca.com/2017/07/03/…
- 技能事例—根据 DDD 思想的技能架构战略调整:www.6aiq.com/article/164…
- 中文图
作者：京东物流 李国梁
来源：京东云开发者社区自猿其说Tech
