国际知名的信息技术研究和分析公司Gartner曾预言，到2022年，50%以上的公司将采用低代码开发平台，来进行企业应用定制。低代码的声音已经出现了很长时间，我们似乎还是将其定义为新生事物。
那么，低代码开发平台是什么呢？
“低代码开发”指的是一种用于快速设计和开发软件系统，且手写代码量最少的方法，它可以帮助您更快、更可靠地提供价值。通过在可视化设计器中，以拖拽的方式快速构建应用程序，您可以跳过基础架构以及可能会让您陷入困境的技术细节，直接进入与业务需求紧密相关的工作。
在低代码开发平台，技术人员和业务专业人员可通过图形界面（而不是传统的计算机编程）来创建业务应用程序，通过拖拽式的UI组件及可视化模型来代替一部分甚至全部的编码工作，而项目组件（如前、后端代码和配置文件）则可根据标准化的工具自动生成。
创意甚至可以成为任何业务的支柱。创意所带来的种种价值，不仅对经营公司的人、也对他们的客户，都会产生强烈的影响。
低代码开发平台的出现，可以说打破了业务人员与IT人员之间的界限，大家都可以通过简单的学习，去自行开发一款适合自身需求的业务应用。例如，销售人员可以根据客户需求、销售流程等因素，通过可视化拖拽式操作，快速创建一款销售管理软件，其中能包含业务流程、订单跟踪、数据分析等功能，而无需过分依赖IT人员，让他们从繁忙的工作抽身出来，从而大大缩减时间成本和人力成本。
Zoho Creator就是这么一款低代码开发平台，你无需准备太多的开发知识，甚至是0基础，通过简单的操作就能让你快速将想法转化为成熟的应用程序。
随着市场竞争的逐步激烈，企业对于应用程序的需求在不断攀升，而且，快速开发已经成为企业制胜市场的关键因素。Zoho Creator不仅直观，而且还带有许多易于使用的插件，模板等，使作为企业主、业务人员的你，可以创建自己的自定义数据库应用程序。

MVC是一种设计模式，这种模式的理念是将复杂的代码分为三个模式，MVC主要解决表现层的问题。

浏览器访问表现层（Controller）-->表现层访问业务层-->将数据封装到(Model)-->再通过（View）渲染

模块(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呈现出如下的结构：
cloudstore-adaptercloudstore-appcloudstore-domaincloudstore-infrastructurecloudstore-clientstart
当业务变得复杂时，这种分层结构自然比没有分层要好。这也是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架构的设计原理。希望能够帮助广大程序员培养良好的编程习惯和思维。
相关链接
[1]https://softwareengineering.stackexchange.com/questions/178927/is-there-a-difference-between-a-component-and-a-module
[2]https://stackoverflow.com/questions/2702816/module-vs-component-design
[3]https://medium.com/swlh/angular-component-vs-module-b8c7347c604e
[4]http://www.techweb.com.cn/cloud/2020-10-27/2808376.shtml
来源：阿里云开发者社区

适合受众：2年以下的初级程序员和0基础的门外汉



内容大纲：

1.为什么需要一个好的代码结构

2.什么样才是一个好的结构

3.每一个分类代表什么含义

4.是否适用于WEB，Android和IOS？

5.进一步的学习的话，是要学习系统架构么？

 

一 为什么需要一个好的代码结构

 

好的代码结构并不仅仅是为了看上去清晰，它更像是我们对一个系统的拆解和组装。
	
好的代码结构可以让你在遇到代码交接这种天理不容的情况时，减少提刀砍人的可能性。
	
好的代码结构可以让多人协作开发更容易，而不会缠缠绵绵到天涯，再相爱相杀。
 

 

我们经常形容一个坏的代码结构，像屎一样。



 

 

 

我们称它为一坨，说真的，接手过烂代码之后，真的找不到比屎更能描述自己感受的词了。

 

“屎”代表着混乱，一坨，各种杂质。接手一堆烂代码的难度就像是用一坨屎来做沙画。

 

有时候我们还会用一团毛线来形容代码，大概是这样的。



 

 

对的，这种感受是绝对不会错的。而我们要做的就是把这团毛线，变成像瑞士军刀一样的清晰。

 




 

 

 

你们觉得哪个更有成就感？

 

 

二 什么样才是一个好的结构

好的结构应该保持单一职责。
	
好的结构应该是通用的。
	
好的结构应该是有明确定义的。
 

这其实就是所谓的脚手架提供的最大的价值，一般而言，Java，Android，IOS都有一套明确的框架体系，JS本来没有，后来有了，然后。。他们就打起来了。

 


就像。。。他们一样。

 

 




该喷火的喷火，该喷水的喷水，每个人分工都很明确。




 

 

三 每一个分类代表什么含义

1.Model

Model是模型，一般而言，会有人分的更细，VO，DTO等等。我并不推荐分的更细，这个Model常常和持久化的数据一一对应，如Mysql和MongoDB。

Model承载的作用就是数据的抽象，描述了一个数据的定义，Model的实例就是一组组的数据。整个系统都可以看成是数据的 流动，既然要流动，就一定是有流动的载体。

这个红圈标的就是Model。它就应该是一个纯数据的集合，就是被各种东西传来传去，被各种加工处理的数据团。

通常会有很多Model，一条业务流就是对应一条或者多条数据流，拿知乎为例子。

文章是一个Model，一般叫Article，包括Title，Summary，Author，Content等等。

评论也是一个Model，一般叫Comment，包括Content，userID等等。

对于初学者而言，第一个要学会，就是建模，把业务逻辑映射成数据模型。

 

2.Util

 

Util是工具的意思，一般来说，常常用来描述和业务逻辑没有关系的数据处理。

Util一般要和私有方法对比：私有方法一般来说是只是在特地场景下使用的，私有方法越多，代码结构越乱。常见的重构策略就是首先从一个越长行数的代码里抽象出若干个私有方法，然后再抽出公用的Util。

如果有可能，尽可能的少用私有方法，而是把他换成一个公用的Util，代表他和业务逻辑是不相关的。通常命名也是ArticleUtil，CommentUtil之类的。



 

像这种打包，不管是充气娃娃还是别的什么东西，都打包。你可以理解为图中的黑衣人就是一个Util。

 

某中程度上也会跟Service有点接近。但是Service一般而言，都是包含有业务逻辑的，很少能做单元测试。

Util一般来说，就是一个明确的输入和一个明确的输出结果。单元测试中，多数也是来测试Util。

积累好自己的Util是一件很重要的事儿。

3 Service

Service比Util的概念大很多，它的重点是在于提供一个服务。这个服务可能包括一系列的数据处理，也有可能会调用多个Util，或者是调用别的服务。总归一句话，就是，有什么事情，你来找我。



 

就像这个图上的妹妹一样，她就是一个Service，她能提供什么样的服务？这个是必须定义好的。如果是洗脚，她要帮你脱鞋，要端盆子烫你的脚。这里面，你的脚就是一个Model，盆子里的水相当于Util，不管里面放进去啥都能烫一烫。

 

帮你脱鞋可以是一个Service，也可以是一个私有函数，也可以是一个Util。看你的是让这个小妹妹帮你脱，还是别的小妹妹脱，还是自动脱鞋机。

如果是你自动脱。。。说明你在Model里面加上了功能，你的脚就不是一个纯粹的数据模型了，而是一个包含业务功能在里面的充血模型。

这样不好。老老实实让小妹妹帮你拖鞋不好么。

4.Dao

Dao一般而言，都是用来和底层数据库通信，负责对数据库的增删改查。



 

是的。他就是一个Dao。他从来不关心这些货物要去哪里，他只关心。入库，出库，查询和更换。

 

所谓的CRUD就是创建，读取，更新，删除。

Dao最好都是要独立出来。

到现在为止，最佳实践就是一个Service只对应一个Dao。Service会做一些额外的检查，如货物是否损坏，入库单是否完整，等等等等。

我并不推荐在Service里调用多个Dao，也推荐在Service里调用多个Service，大多数情况下我都不推荐这么干。

具体原因以后再说，这也是一个开放性的话题。

现在我们分清楚了Model，Util，Service和Dao，可是谁来做总的调度呢？

5.Controller

控制中心，所有的指令，调度都从这里发出去。

哪一个Service做什么事儿，谁的数据提供给谁，一般而言，都是在Controller里实现的。

Controller也是最常见的容易产生脏代码地方，通常他们会把一些不该放到Controller里东西也放进来。

大概的感觉就是这样的。



 

干嘛的都有。想想如果打小针，抽血，查尿也混杂到门诊大厅的感觉？

 

可是大部分人写代码就是这样的。

四.是否适用于WEB，Android和IOS？

Java后台是有很清楚的结构的，毕竟在JSP里写Sql语句的蛮荒时代已经过去了。

Android本身就是一个良好的框架体系，基本上问题也不大，最多就是MVP和MVC的差别之类。

IOS虽然没有官方提供这种框架体系，特别是很多人喜欢直接在Dict里用key取数据，这本身就破坏了代码的层次性。

但是毕竟是有李明杰提供的Json解析Util,只是各家要求的力度而已。

最难以理解的是WEB，也就是JS。

我不是在黑JS，我是在黑JS程序员。分层结构一直都不是JS社区里最注重的，在JQuery时代更是如此，不管是Html还是JS还是CSS混在一起是正常的。

那个时候叫插件，现在改名了，叫组件。

你很难在JQuery里找到一套清晰的分层结构，就跟十几年前所有的人都在Jsp里写逻辑语句的道理差不多。

直到google的大神偶尔遛达过来一看，咦？你们怎么还在刀耕火种？我来给你们加点现代感的东西吧。

于是Angular横穿出世，一次性的构建了一个清晰的框架结构。每次看到Angular的时候都忍不住 惊叹，原来前端代码也可以这样！



 

而原来的感觉就是这样。。。



 

 

 

现在基本上可以分成两大阵营，一个是React和Vue，一个是Angular。

 

 

React和Vue本身更偏得于插件化，哦，不，组件化。所以他们需要便宜桶，来拼接整个前端的架构体系。

Angular却是有典型的Java架构风格，妥妥的硬汉子。

所以，实际上说，这套体系也是可以应用在WEB上的，就像Android和IOS一样的，但是你喜欢，或者不喜欢，自己选啦。

五 进一步的学习的话，是要学习系统架构么？

是的。进一步要学习，并不仅仅是学习系统架构。

这里还没有讲到Service的设计，互相之间的调用，解耦，服务之间的通信和管理。

消息队列这个神器还没有登场，MongoDB这种战略要塞也没出场。

所以以上内容，仅适用于2年以内的各种工程师。