简介：如何定义架构？利用架构的因素有哪些？什么是利用架构中的分类思维？开源利用架构 COLA 的作者张建飞介绍他在 COLA 架构设计中的一些思维教训，分享他的利用架构之道。
模块（Module）、组件（Component）、包（Package），这些概念对于咱们技术同学并不生疏，但并不是所有人都能了解其要义。
深刻了解之后，我才发现，其背地的深意是分类思维。而这种分类也是利用架构的外围所在，通过不同粒度、不同档次的分类，把简单的软件系统实现管制在能够被了解、被保护的水平。否则，对于动则上 100 万行代码的软件，人类基本没有方法了解和保护。
试想一个极其状况，如果没有这些概念帮助咱们分类，咱们把所有业务逻辑都写在一个类外面，会是什么样的后果呢？咱们很多的“非人类”零碎，正是因为没有进行正当的分类造成的。
晚期，我不喜爱 JavaScript 的一个重要起因，正是因为其短少像 Java 中 package 和 jar 的概念，导致代码的组织模式比拟涣散、随便。这个问题直到 ES6、React 才失去比拟好的解决，在此之前，前端工程师不得不依附 seaJS，requireJS 这些框架来做模块化、组件化的事件。
至此，你可能有疑难，分类有什么魔力？怎么就成了利用架构的外围了呢？客官别着急，由我细细道来。
分类的重要性
所谓分类，就是根据肯定的规范对给定的事物进行组别的划分。咱们人类天生就有分类的本能，例如，当咱们察看上面这张图的时候。
无论是谁，乍一看到下面的六个黑点，都会认为共有两组墨点，每组三个。造成这种印象的起因次要是，人类大脑会主动将发现的所有事物以某种继续组织起来。基本上，大脑会认为同时产生的任何事物之间都存在某种关联，并且会将这些事物按某种逻辑模式组织起来。
之所以咱们大脑有这样的本能，是因为人一次可能了解的思维或概念的数量是无限的。正如乔治米勒在他的论文《微妙的数字 7》中提出的。人类大脑的短期记忆无奈一次包容 7 个以上的记忆我的项目。所以，当信息量过大时，唯有归类分组能力帮忙咱们去了解和解决问题。
其实，自古及今，人类始终在做着归类 / 分类，早在春秋时期，《战国策》中就提出过“物以类聚，人以群分”的概念。
在互联网行业，咱们会对客户进行分类，而后针对不同的客户进行分层经营，也是这个情理。
平时咱们所说的剖析和综合的背地，其实就是分类能力。剖析是在一个类外面找差异性，综合是在不同事物中找分割、找共同性，而这个共同性相当于分类的维度。
分类思维的能力，间接体现的就是看透事物本质的能力。
利用架构中的分类思维
概念定义
在探讨架构之前，咱们先来明确一下 Module、Component 和 Package 这几个概念。
因为这些概念始终以来存在不小的歧义。通过 Stack Overflow 上几十篇询问这些概念差别的发问，以及形形色色的答复就能可见一斑。
在一篇 Stack Overflow 的帖子 [1] 中，咱们看到这样的答复：
The terms are similar. I generally think of a “module” as being larger than a “component”. A component is a single part, usually relatively small in scope, possibly general-purpose.
然而，另一篇 Stack Overflow 的帖子[2]，却有着不同的答案：
There is no criteria to measure which one is greater than the other. One component can contain list of modules, and one module also can contain many components.
在《实现畛域驱动设计》一书中，作者有这样的形容：
If you are using Java or C#, you are already familiar with Modules, though you know them by another name. Java calls them packages. C# calls them namespaces.
然而，在 AngularJS 的设计文档 [3] 中，它对 Module 和 Component 是这样定义的：
The module can be considered as a collection of components, Each component can use other components. One of many modules combines up to make an Application.
通过比拟，联合我本人的认知，我更同意 AngularJS 外面的定义，即 Module 是比 Component 更大的概念。比方在 Maven 中，Module 是组成 Application 的第一级档次，而 Component 的粒度个别比 Module 要小，多个 Component 会组成一个 Module。
因而，在进一步探讨之前，我特意对这些概念做如下定义：
- 利用（Application）：利用零碎，有多个 Module 组成，用方框示意。
- 模块（Module）：一个 Module 是有一组 Component 形成，用正方体示意。
- 组件（Component）：示意一个能够独立提供某方面性能的物件，用 UML 的组件图示意。
- 包（Package)：Package 绝对比拟 tricky，它是一种组织模式，和粒度不是一个维度的，也就是说，一个 Component 能够蕴含多个 Package，一个 Package 也能够蕴含多个 Component。
基于下面的定义，他们的表示法（Notation）是这样的：
利用架构的因素
对于架构的定义有很多，我最喜爱，也是最简洁的定义是：
即架构是一种构造，是由物件（Components）+ 物件之间的关系 + 领导准则组成的。
利用架构也是如此，从大的层面来说，企业级利用都逃不过如下图所示的三层构造，即前端、后端和数据库。
对于后端开发来说，应用层是咱们的主战场，也是整个零碎最简单的局部（当然，前端也不简略），所有的业务逻辑都汇聚在此。所以，对于应用层，咱们须要进行进一步拆分，而不仅仅是在这里写业务逻辑就完事了。
对应用层的进一步分层，就造成了 COLA 所提倡的四层构造，对应到 Maven 中，就是有 4 个 Module，编译打包之后会有 4 个 Jar。一个典型的利用，其 Module 呈现出如下的构造：
<modules>
<module>cloudstore-adapter</module> <!--Adapter 层 -->
<module>cloudstore-app</module> <!--App 层 -->
<module>cloudstore-domain</module> <!--Domain 层 -->
<module>cloudstore-infrastructure</module> <!--Infra 层 -->
<module>cloudstore-client</module> <!--RPC SDK-->
<module>start</module> <!--SpringBoot 启动 -->
</modules>当业务变得复杂时，这种分层构造天然比没有分层要好。这也是 COLA 始终致力要去解决的问题——管制复杂度。
从 COLA 1.0 的事无巨细，到 COLA 3.0 的化繁为简。我慢慢明确，COLA 作为利用架构，其外围不是去提供性能，而是提供基模（Archetype）。
在 1.0 的时候，COLA 提供了 Interceptor 能力，提供了 Event Bus 能力，提供了扩大点能力。一个是我认为大家“须要”这些，另一个是感觉 NB 的框架就应该八面玲珑，没有几个高级性能都不好意思开源。事实证明，我犯了一个惯性谬误——适度设计。Interceptor 齐全能够用 AOP 代替，外部事件和扩大点很少被用到。所以在 COLA 3.0 的时候，果决的去掉了这些“鸡肋”，只保留了扩大点性能。
回归到架构的实质，COLA 的外围应该是规定利用的构造和标准，即利用架构基模（Archetype）。而不是去纠结那些精益求精的性能。
降级到 COLA 3.1
实际上，这样的回归工作，COLA 3.0 曾经做的差不多了。在这次 3.1 的降级中，除了进一步去除了 Event Bus 的性能之外，最重要的就是从新标准了分包策略，和裁减了原来管制层（Controller）的职责。
分包策略调整
分层是一种在性能维度上的横向切分，即每一层都有本人的职责。
- Adapter 层：路由用户 request + 适配 response。
- App 层：接管申请，联结 domain 层一起做业务解决。
- Domain 层：畛域模型 + 畛域能力。
- Infrastructure 层：技术细节（DB，Search，RPC..）+ 防腐（Anti-corruption）。
分层解决没有问题，只是这种性能划分，会带来一个问题，即畛域维度的内聚性会收到影响。当一个 application 只负责一个畛域的时候没有问题。然而，当一个 application 蕴含多个业务畛域的时候，这种内聚性缺失的弊病就比拟显著了。
更好的分包策略是按畛域划分，而不是按性能。因为，畛域更内聚，性能是为畛域服务的，应该归属于畛域。
然而，不巧的是，在 COLA 利用架构外面，咱们要综合横向性能维度的划分，和纵向畛域维度的划分，两个都很好，两个都想要。怎么办？咱们能够采纳物理划分和逻辑划分相结合的方法。
横向上，咱们用 Module 做有档次划分，属于物理划分。纵向上，通过 Package 来进行逻辑划分。最初，造成一个如下的构造：
依照这个思维去分包，在工程中，Module 下的顶层 package 不再是性能，而是畛域：
依照畛域的分包策略至多会带来两个益处：
- 零碎的可了解性和可维护性更好，用文言说，就是找货色更好找了。
- 不便当前的拆分，比方下单域（Order）变得越来越简单，须要拆出去，咱们只须要把 Order 上面的货色迁徙到一个新利用就好了。
用 Adatper 代替 Controller
Controller 这个名字次要是来自于 MVC，因为是 MVC，所以自带了 Web 利用的烙印。然而，随着 mobile 的衰亡，当初很少有利用仅仅只反对 Web 端，通常的标配是 Web，Mobile，WAP 三端都要反对。
在这样的背景下，广义的管制层曾经不能满足需要了，因为在这一层，不仅仅要做路由转发，还要做多端适配，相似于六边形架构中的 Driving Adapter 的角色。鉴于此，咱们应用适配层（Adapter）替换掉了 Controller，一方面，是为了响应六边形架构；另一方面，确实也是须要做多端适配。
基于这样的变动，我重构了 COLA Archetype，把 Adapter 作为一个档次凸显进去。实际上，Infrastructure 也是适配器，是对技术实现的适配（或者叫解耦），比方，我须要数据来帮忙结构 Domain Entity，然而我不 care 这个数据是来自于 DB、RPC 还是 Search，或者说，我能够在这些技术实现中进行自在切换，而不影响我 Domain 层和 App 层的稳定性。
革新后的 COLA 在架构格调，模块、组件以及分包策略上都会有所调整，具体变动请参考上面两张图。
COLA 架构图：
COLA3.1
COLA 组件关系图：
组织架构中的分类思维
这么重要的思维能力，其利用必定不仅仅局限于架构设计的领域。开篇曾经说过了，分类是咱们人类的本能，是剖析和综合问题的重要伎俩。
生产关系决定生产力，好的组织构造会助力业务倒退，反之，则会拖业务的后退。因而，大公司的 CEO 每年都会花很多工夫在组织设计上，这也是为什么，在大厂，每年咱们都会看到不小的组织调整。
看到一篇文章《苹果公司的组织架构是怎么的》[4]，外面介绍了苹果胜利和其优良的组织架构有关系。如下图所示，传统企业偏差于业务型组织，而高科技企业偏差于职能型组织。
有没有感觉苹果的组织架构，和咱们的 COLA 思维是一样的：），物理上，依照职能划分；逻辑上，依照业务和产品划分。
苹果这样的组织设计，是因为它是技术和翻新驱动的公司，合作老本不是最大的问题，短少专业性（技术不行），短少翻新才是攸关生死的大问题。所以他宁肯就义协同效率，也要确保专业性，也就是说，做摄像头的只做摄像头，做 iOS 的只做 iOS，技术 leader 间接向 CEO 汇报，能够决定产品的倒退方向。因为他们在这个畛域更业余。
很早以前，史蒂夫·乔布斯就有这样的观点：苹果公司的经理们应该是他们治理畛域的专家。在 1984 年的一次采访中，他说：
咱们在苹果经验了那个阶段，过后咱们进来想，哦，咱们要成为一家大公司，让咱们雇佣业余的管理人员。咱们进来雇了一群业余的管理人员。一点也不论用……他们晓得如何治理，但他们在业余方面什么都不晓得。如果你是一个平凡的人，为什么你想为一个你什么都学不到的人工作？你晓得什么是乏味的吗？你晓得谁是最好的经理吗？他们是平凡的集体贡献者，他们素来都不想成为一名管理者，但却决定本人必须成为，因为没有其他人可能杰出地实现工作。
说实话，看完这篇文章，我很感叹，一方面是拜服乔布斯的洞见能力，另一方面也为咱们这个行业感到唏嘘，业务技术也是技术啊，却没有一个像样的培养倒退技术的环境和土壤。
现在，业务技术 Leader 还有多少是专一在技术上呢，俨然都变成了业务 Leader。如果技术 Leader 都变成了纯管理者，那么谁去关怀技术，谁去关怀代码，谁去关怀工程师的成长呢？
分类学是迷信也是艺术
最初，我还是要中庸一下，分类很重要，但同时也很难，带有肯定的主观性。就像比尔. 布莱森在《万物简史》里说的：
分类学有时候被形容成一门迷信，有时候被形容成一种艺术，但实际上那是一个战场。即便到了明天，那个体系比许多人认为的还要凌乱。以形容生物根本构造的门的划分为例。许多生物学家保持认为总数 30 个门，但有的认为 20 来个门，而爱德华在《生命的多样性》一书里提出的数字高达令人吃惊的 89 门。
咱们察看事物的视角不同，对问题的认知水平不同，得进去的分类也会不同。就拿 COLA 来说，直到现在的 3.1 版本，我集体认为其分层和分包的形式才绝对比拟正当。然而，很有可能在前期的迭代中，分类形式又会扭转。
组织架构的分类形式也是一样，依照业务和职能划分，都能够。要害看其分类是否匹配你组织的个性，没有最好的分类，只有最合适的。
除了本文分享的分类思维，更多的思维能力还能够参看作者的新书：《代码精进之路：从码农到工匠》。这是一本为业余程序员而写的书，次要分为技能、思维和实际三个局部，具体介绍了编程技巧和方法论、形象能力、分治思维、常见的利用架构模式，以及 COLA 架构的设计原理。心愿可能帮忙宽广程序员造就良好的编程习惯和思维。
举荐浏览
为什么阿里巴巴的程序员成长速度这么快？
霸榜 GitHub 的 Offer 来了原理篇+框架篇，凋谢分享；
50W 年薪程序员须要的技术栈剖析
看完三件事❤️
如果你感觉这篇内容对你还蛮有帮忙，我想邀请你帮我三个小忙：
点赞，转发，有你们的『点赞和评论』，才是我发明的能源。
关注公众号『Java 斗帝』，不定期分享原创常识。
同时能够期待后续文章 ing????