为什么说应用架构需要分类思维？

若何定义架构?应用架构的要素有哪些?什么是应用架构中的分类思维?开源应用架构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出现出如下的构造：

1. <modules>
2. <module>cloudstore-adapter</module> <!--Adapter 层-->
3. <module>cloudstore-app</module> <!--App 层-->
4. <module>cloudstore-domain</module> <!--Domain 层-->
5. <module>cloudstore-infrastructure</module> <!--Infra 层-->
6. <module>cloudstore-client</module> <!--RPC SDK-->
7. <module>start</module> <!--SpringBoot启动-->
8. </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组件关系图：

更多关于COLA 3.1.0的信息，可以拜访：https://github.com/alibaba/COLA 。

组织架构中的分类思维

这么重要的思维才能，其应用肯定不仅仅局限于架构设计的范畴。开篇已经说过了，分类是我们人类的本能，是分析和综合问题的重要手段。

临盆关系决定临盆力，好的组织构造会助力营业成长，反之，则会拖营业的后腿。是以，大年夜公司的CEO每年都邑花很多时光在组织设计上，这也是为什么，在大年夜厂，每年我们都邑看到不小的组织调剂。

看到一篇文章《苹果公司的组织架构是如何的》[4]，里面介绍了苹果成功和其优良的组织架构有关系。如下图所示，传统企业偏向于营业型组织，而高科技企业偏向于本能机能型组织。

有没有感到苹果的组织架构，和我们的COLA思惟是一样的：)，物理上，按照本能机能划分;逻辑上，按照营业和产品划分。

苹果如许的组织设计，是因为它是技巧和立异驱动的公司，协作成本不是最大年夜的问题，缺乏专业性(技巧不可)，缺乏立异才是攸关逝世活的大年夜问题。所以他宁可就义协同效力，也要确保专业性，也就是说，做摄像头的只做摄像头，做iOS的只做iOS，技巧leader直接向CEO报告请示，可以决定产品的成长偏向。因为他们在这个范畴更专业。

很早以前，史蒂夫?乔布斯就有如许的不雅点：苹果公司的经理们应当是他们治理范畴的专家。在 1984 年的一次采访中，他说：

我们在苹果经历了那个阶段，当时我们出去想，哦，我们要成为一家大年夜公司，让我们雇佣专业的治理人员。我们出去雇了一群专业的治理人员。一点也不管用……他们知道若何治理，但他们在专业方面什么都不知道。假如你是一个巨大年夜的人，为什么你想为一个你什么都学不到的人工作?你知道什么是有趣的吗?你知道谁是最好的经理吗?他们是巨大年夜的小我供献者，他们从来都不想成为一名治理者，但却决定本身必须成为，因为没有其他人可以或许出色地完成工作。

说实话，看完这篇文章，我很感慨，一方面是佩服乔布斯的洞见才能，另一方面也为我们这个行业认为唏嘘，营业技巧也是技巧啊，却没有一个像样的培养成长技巧的情况和泥土。

如今，营业技巧Leader还有若干是专注在技巧上呢，俨然都变成了营业Leader。假如技巧Leader都变成了纯治理者，那么谁去关怀技巧，谁去关怀代码，谁去关怀工程师的成长呢?

分类学是科学也是艺术

最后，我照样要中庸一下，分类很重要，但同时也很难，带有必定的主不雅性。就像比尔.布莱森在《万物简史》里说的：

分类学有时刻被描述成一门科学，有时刻被描述成一种艺术，但实际上那是一个疆场。即使到了今天，那个别系比很多人认为的还要纷乱。以描述生物根本构造的门的划分为例。很多生物学家保持认为总数30个门，但有的认为20来个门，而爱德华在《生命的多样性》一书里提出的数字高达令人吃惊的89门。

我们不雅察事物的视角不合，对问题的认知程度不合，得出来的分类也会不合。就拿COLA来说，直到如今的3.1版本，我小我认为其分层和分包的方法才比拟较较合理。然而，很有可能在后期的迭代中，分类方法又会改变。

组织架构的分类方法也是一样，按照营业和本能机能划分，都可以。关键看其分类是否匹配你组织的特点，没有最好的分类，只有最合适的。

除了本文分享的分类思维，更多的思维才能还可以参看作者的新书：《代码精进之路：从码农到工匠》。这是一本为专业法度榜样员而写的书，重要分为身手、思惟和实践三个部分，具体介绍了编程技能和办法论、抽象才能、分治思惟、常见的应用架构模式，以及COLA架构的设计道理。欲望可以或许赞助广大年夜法度榜样员培养优胜的编程习惯和思维。