一 背景
1.1 架构中的问题识别
需求分析，架构实现，（新需求，架构改动）* n = 推倒重来。
这个过程是一个循环往复的过程，有的产品每年都会推倒重来一次。
而这个过程是如何造成的呢？原因之一是每次迭代过程中都没有用正确的架构方法来进行迭代造成的，就像在歪楼上继续加盖楼层一样，最终还是会倒塌（不过这个原因并不是唯一的原因，其他原因留到后续文章中阐述）。
这真是一个悲伤的故事，但是又是一个时常发生的故事。或者说我们大多数人都经历过的场景。
要解决这个问题，那就需要在每次迭代中，都需要用正确的姿势对不对？要用对姿势其中有一个重要的原因是架构。就像一幢大楼，架构设计得越有问题，这幢大楼被重造的可能性就越大。
这里正确的姿势到底是什么姿势？接下来本文会阐述一整套架构方法论，该方法论中包含了详细的架构推导逻辑，帮助我们在工作中在各个粒度，各个层次做好架构工作。
我们后续的文章中将会着重阐述如何通过自底向上以及自顶向下的两种架构思考方式来解决这些问题，但是在那之前，我们还是先来聊聊什么叫“架构”。
1.2 什么是架构？
大概是在 11 年前左右，在土豆网做广告平台，同时也做视频 CDN 的相关事情，当时做一个服务，基础架构是 lighttpd + squid + tomcat，将静态资源分离到 httpd，get 请求使用 squid 缓存，智能路由使用 HTTP post 请求，并让 tomcat 提供服务，当时就觉得这就是架构。再后来，做了视频 CDN 相关的基础建设的工作，就觉得这就是做架构，关键那个时候也没有人告诉我们什么架构，自己不知道自己不知道。
再后来慢慢成长，又去做了几年中间件（包括高性能 RPC 和 JSR-170），然后就觉得这也是做架构。当时也没有前辈跟我讲什么是架构，那个时候的我对架构是没有体系化认知的，都是凭着感觉做的，是不知道自己不知道。
再后来，来到了阿里做应用研发和架构了，发现业务开发中也包含了各种方法论，而以前看过的建模相关的资料，在中间件等基础设施上也没有太大的感觉，反而在业务技术领域发挥出了巨大的光芒。也发现越靠近用户的架构，随着企业的慢慢壮大会变得越来越重要。这个时候的我对架构认知是知道自己不知道了。
既然知道自己不知道了，那么就是要追寻它，曾经我和不少业务的研发同学讨论过架构是什么，撇去基础设施架构和物理架构等视角不谈（这些视角聊起来也是篇幅很长的），我挑应用逻辑架构并从几个角度来尝试描述一下：
1）从架构的总原则的角度：尽可能简单（在当前场景下要尽可能简单便于扩展和维护），但是不能太简单（相对而言太过于简单可能在场景上有所遗漏）.
2）从架构的目的角度来考虑：既要解决过去的问题，也要解决现在的问题，还能适度解决未来的问题，这些问题既包含技术问题，更包含业务问题。
3）从形态之 2 维的角度来考虑：架构就是横的问题，和竖的问题。横就是分层，竖就是分区，横竖都有抽象的事情要做。
4）从形态之 3 维的角度来考虑：架构是三维的，在 x 轴和 y 轴上有横竖的问题，在z轴上还有粒度的问题。
5）从时间轴的角度来考虑：架构不是一层不变的，是随着业务的发展在不断变化的。
可以看出，虽然我试图从以上几个视角对架构进行了描述，但是显然这些描述都是见仁见智的观点，是从某个角度来看架构。内心里我觉得自己提炼的高度是不够的，实践中的总结必须和业界的知识结合起来，我必须学习前人已经总结的体系。于是在不断的搜集资料的过程中，我发现在 ISO/IEC 42010:20072 中对架构有如下定义：
The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
这个最顶层抽象我个人觉得非常到位，根据这个定义，显然，我们在架构中需要：
- 职责明确的模块或者组件
- 组件直接的关联关系非常明确
- 需要有约束和指导原则
这个架构的定义很简练，很实在。小到一个玩具，大到一个国家的运作都可以隐含着这样的内容。
但这是一个广义上定义的架构，经过一些总结思考，我觉得实际上具体到我们日常的工作中，在不同的层次，会有更加精细化的架构分类。
1.3 架构有哪些分类
在工作中我遇到不同职位的人从不同的角度来描述架构，但是我们鲜有能达成共识的，刚开始我也不知道为啥讨论不到一块去，后来经过一段时间的纠结和深入仔细的思考后，我发现很多时候大家描述的架构都不是同一个角度的东西，于是我尝试从如下几个角度划分架构的类别，以帮助我们在不同的场景和不同的人聊天时大家可以聚焦，明确我们到底是在讨论哪种架构，以提升沟通效率，并尽快达成共识，目前这个划分已经在我们团队基本达成共识。
值得注意的是，不管下面哪种分类的架构，都符合上一节总的架构的定义：模块（组件）+ 关系 + 约束 & 原则。
1. 产品功能架构
这个是产品经理最喜欢讲的架构，一般来说，讲我们有什么功能的时候，产品功能架构描述的是能做什么，受众群体一般是使用产品的同学。如果我们做软件设计时，不应该产出这玩意，而是应该产出应用逻辑架构和应用物理架构。但是一旦我们要对外宣讲我们的产品，比如我们的接口有啥用，应该怎么用，这个时候我们讲的应该是产品功能架构。
- 目的：指导用户使用产品，所以模块的聚合是从用户视角出发的
- 受众：使用产品的人
- 包含的内容：阐述产品功能模块的能力：比如一辆汽车，方向盘有什么功能，方向盘的按钮上各区域的功能是什么，仪表盘分成哪些功能模块，每个功能模块有什么作用，油门踏板有什么作用，刹车踏板有什么作用。但是也不排除有些高阶用户需要明确知道变速箱的齿比等信息，所以在产品功能架构图上也可以描绘出来。
- 命名：这里命名需要考虑如何取一个吸引人的名字（同时又能表达产品的能力）来吸引我们的用户前来使用，比如说以前经常有产品套用“纳米”，又有产品套用“绿色”等等。
2. 业务能力架构
用来分析业务，业务概念架构是指拥有哪些业务模块，且各自的能力是什么，这张图有助于我们分析和理解业务需求，也有利于产品经理分析业务。所以业务概念架构和业务概念模型都是用在分析阶段。
- 目的：研发人员和业务人员理解业务内在的概念和联系。
- 受众：研发人员和业务人员，主要是给规划业务的人使用。
- 包含的内容：业务能力，能力中的子能力。
3. 应用逻辑架构
软件设计本身，模块，粒度，职责，复用，等等，在讲解软件设计的时候，使用的是这个架构图，这个架构图是通过系统模型和业务概念架构推导而来。所以系统模型和应用逻辑架构都是用在软件设计阶段。
- 目的：指导软件的研发。
- 受众：研发人员，各层级架构师，各层级技术管理者。
- 包含的内容：阐述架构中各模块的职责：如系统模型，技术模块，技术模块的关系，技术模块的核心抽象，如何用设计模式来让架构符合软件设计原则，等等。如果拿汽车举例，那就是发动机模块中包含了哪些子模块（活塞，曲轴，连杆，缸体，缸盖，等等）发动机模块和变速箱模块之间的关联关系是什么，如何协同工作，和底盘的关联关系是什么，如何协同工作。发动机，底盘，变速箱，电子系统在整辆汽车中的职责，关系，约束是什么。这些都是用来指导汽车研发的。而不是指导用户如何使用这辆汽车的。
- 命名：这里的命名需要朴实无华，精准的描述出职责，华而不实反而让技术的同学无法理解这到底是什么玩意，导致实施的时候职责放错地方，挖下大坑让后人来填。
4. 应用物理（部署）架构
软件部署时的架构，这张图推导自应用逻辑架构，推导时重点逻辑架构如何落地，比如使用何种微服务容器，逻辑架构的模块落地时应该是 package，还是应用，也有可能是一组应用，是不是要跨机房部署，甚至跨国部署等等。还需要考虑稳定性，性能，成本等话题。
5. 基础设施架构
选择什么样的中间件，存储，监控，报警，等等。
6. 等等
1.4 能力和职责的区别
在日常的架构讨论中，有的同学经常谈架构的能力，有的同学经常谈架构的职责，那么能力和职责有什么区别？跟产品的同学打交道多了之后，发现产品同学很多都是讲能力，后来技术的同学也开始讲能力，而通常我们架构的同学原来讲的都是职责，两者有什么区别呢，我说说自己的理解：
1. 能力（产品功能模块的能力）
是指一个产品能做什么，比如中台本身是一个产品，对使用中台的同学来说，我们应该讲中台的能力（其实是在讲中台这个产品的能力）。所以讲能力是讲给架构的使用者或者其他想了解的人来听的。
2. 职责（逻辑架构中各模块的职责）
是指架构内模块的职责，用来指导开发，比如中台研发的同学，应该讲架构的职责，依赖，约束。所以讲职责是讲给研发的同学，讲给域内的架构师，讲给域内的管理者来听的，总的来说就是讲给架构的实现者来说的。
简单来说就是：能力是指产品的能力，职责是指架构内部的职责。如果架构本身也是一个产品需对外输出（如中台，或者其他技术框架作为产品输出），则对外输出时，我们应该讲这个技术产品的能力（这个时候技术的同学也就开始讲能力了）。所以当我们讨论问题的时候，如果有的人在谈产品能力，有人在谈架构内部职责，那么显然已经不是在讨论同一个话题了，请大家务必注意区分这种情况，差之毫厘，谬以千里，鸡同鸭讲啊。
比如说两个模块 A 和 B，职责不一样，但是依赖了相同的二方库。那我们不能说某个职责在这个二方库里。这个二方库作为某个独立的技术小产品，提供了某些能力。但是履行职责的还是 A 模块或者 B 模块。
1.5 应用逻辑架构的地位
正如前面我们描述的架构分类所描述，有些架构和具体业务是无关的，有些架构是和具体业务息息相关的，比如说应用逻辑架构就是和业务息息相关，它来源于业务的抽象，甚至我们可以说：它是业务线技术架构设计中第一份产出。
既然他是首要的产出，我们就必须要考虑应用逻辑架构中应该包含的三类主题：
- 模块
- 依赖
- 约束
绝大部分的架构问题都可以归纳成这三类主题，这些主题包含哪些内容呢？这就是本文接下来要介绍的内容，应用逻辑架构的设计不需要拍脑袋，是通过科学的方法体系推导出来的。
二 架构的两种推导思路
架构的产出总的来说有两种方式，一种是自顶向下的方式来推导架构，一种是自底向上的推导方式，而且两种方式往往是相互结合来产出最合适的结果。而在业务线的同学，可能接触最多的是自底向上的推导的方式，自底向上的推导的方式也是本文中要重点讲解的架构推导方式。
2.1 自顶向下的架构推导
自顶向下的推导的关键问题在问题定义，如果问题没有被准确的定义，那么自顶向下就无法推导出正确的结果。假设问题被准确的定义了，如何自顶向下推导呢？
2.2 自底向上的架构推导
我们在业务线做开发的同学，每天肯定跟很多需求打交道，这些需求哪里来的？基本上有这三种产出：
- 有些是来自产品方一拍脑袋产生的灵感
- 有些是对数据进行了详细的分析产出的产品策略
- 有些是当前产品中暴露的一个个问题
产品方的这些详细的需求来了之后，我们是如何应对的呢？我们首先和产品方一起讨论产品方案的合理性，在产品方案合理的基础上，我们来开始识别用例，开始了一系列软件工程领域方面的措施。其整体过程如下图所示：
自底向上推导逻辑架构就是最右边代表的那条曲线。
这里基本上就是本文接下来要重点阐述的：如何自底向上推导应用逻辑架构，这个过程就是一个抽象和架构的过程。
那么我们从整体方法论的介绍开始，采用总分总的结构，下面这张图就是应用逻辑架构自底向上的推导路径，这个推导路径是有序的，每个步骤都包含了大量的操作技巧，前一步做好，后一步才有可能得出正确的结果。
这张图中有几个重点：
1）软件研发分成了两个阶段：
- 分析阶段，也是我们常说的问题空间领域建模，关键的一步是业务概念模型的输出，而业务概念模型输出的前置条件是从需求中分解出合理的用例集合。
- 设计阶段，也是我们常说的解决方案空间建模，以及应用逻辑架构。
2）图中存在了箭头这个东西，说明了我们做架构推导的主要的思维路径，也说明做架构不需要拍脑袋，都是根据严密的逻辑推导出来的。
这个严密逻辑基本是一个自底向上的推导过程，底层的模型是通过建模方法演绎出来，逻辑架构中的各个模块是通过归纳的方法推导出来。那么：
- 什么地方应该用演绎，什么地方应该用归纳呢？
- 使用演绎的时候应该使用何种具体方法呢？
- 使用归纳的时候应该使用何种具体方法呢？
我们再留一个悬念，后面再讲。
不管是演绎还是归纳，都是抽象工作的一部分，而且都需要素材，这里的素材就是我们对需求，对业务的理解，以及对技术的深度广度的把握。没有素材，方法论掌握再好也得不出结果。
素材哪里来呢？
业务素材的来源大部分是你需要解决问题所在的领域，比如我们在电商领域，那么我们就要多搜集电商领域的业务知识。如果我们在数据领域，自然要多搜集数据业务的相关知识，以及我们前文中讲到的技术类的相关知识。
而技术素材是要求我们在技术领域不断的钻研，不断的扩展边界，深度不断增加，广度也不断增加。所以对于架构师来说计算机科学与技术是绝对要不断精进的。
2.3 两个方法的区别
自顶向下推导的一个前置条件就是你需要知道猪长什么样，在架构上就是你需要知道这个架构的原来是是什么样子的，解决什么问题的。如果都不知道猪长什么样，那么就无从判断猪是不是适合当宠物了。此处需要有一定的业务领域理解力和领域经验（包含：客户的问题和痛点是什么，怎么分析出来的，当前的架构方案是什么，当前的架构方案是如何解决这个问题的，未来的架构方案如何更好的解决这个问题）。
而自底向上推导则没有这个问题，因为是看着猪来做推导的，知道猪的细节，这个细节的特点如何演绎，如何归纳，最后得出结论。
所以当我们不熟悉一个大的业务的时候，我们自顶向下推导架构的难度是极大的，几乎不能完成。不了解业务或技术情况时定义出来的问题也未必是一个被正确定义的问题，容易给人造成一个印象：瞎指挥。
这个时候如何在没有知识背景的情况下快速落地就得自底向上的来推导架构。在自底向上的过程中慢慢熟悉业务。
但是如果工作中每每都是纯粹的自底向上的推导架构，是无法帮助我们来做技术的前瞻性布局的，此时架构师的成长就遇到的瓶颈，所以此时又要使用自顶向下的架构推导方式。
综上所述，不管是自底向上，还是自顶向下，都是架构师需要掌握的技能。
三 自底向上的架构方法：业务概念架构推导
这部分内容，我在 ICBU，村淘，一达通，菜鸟，AE 现场分享过。尤其是在 AE，一达通和菜鸟，相关的同学都拿出了当时的纠结大家很久的难题，我们一起使用了这样的方法很快就分析出了业务概念模型，并且对模块进行了简要的划分，形成概要的业务概念架构。经过大量的实战，效果是非常明显的。
3.1 模型的 3 个层次
在这里，我把一些常见的概念集中起来，便于大家统一概念：
1）业务概念模型，问题空间领域模型，信息模型是同样的意思，这个层次上的实体我们称之为概念实体，这部分内容是用在需求和业务分析上的，讨论业务概念模型时完全不需要考虑软件的实现，这个过程是一个分析过程，即使不做软件研发，做其他的研发，类似的分析过程也应该是有的。
2）系统模型，解决方案空间领域模型，逻辑模型是同样的意思，这个层次上的实体，我们称之为系统实体，或者逻辑实体，就是各种类，这个是用在软件设计和软件研发上的。
3）存储模型，数据模型，物理模型，在这里也是同样的意思，这个层次上的实体，我们称之为数据实体，或者物理实体，也是用在软件设计上。
这 3 个层次其实是从 3 个角度在看待问题，他们之间是自上而下的转换的关系，这里尤其要注意的两个词是：逻辑的，顺序的推导。
这些不同层次的模型是应用逻辑架构的基础！！！
3.2 模型的推导
3.2.1 用例集合推导概念模型
- 根据用例集合推导业务概念模型
- 根据用例中的动词和量词推导业务概念模型的关联关系
- 在特定的边界内根据模型的职责归纳子域
重要！重要！重要！这里业务概念模型如果没有分析正确，那么下面要搞清楚是不容易的，这个分析部分是软件逻辑架构设计的基础。
这个环节需要我们理解业务，更需要我们掌握问题空间建模这一严谨的方法论，这样我们才能推导出合理的模型，整个过程是非常严谨的，非常符合逻辑的。
我在各 BU 分享现场做的多次实战演练之所以能成功的快速帮助同学们梳理出前面花一两个月都没有理出的模型，完全是因为于现场的同学对业务的理解（因为讨论之前我完全没有了解过对方的业务）和这套方法论（隐含在我的提问方式中）。所以说对业务的理解和方法论，两者缺一不可。
3.2.2 对业务概念模型进行归纳
在模型产出之后，我们要对模型进行归纳。
什么叫归纳？
归纳的意思是将所有的结果和想法合并，变成一种思维概念。或者让某个模型归属于某个已经存在的思维概念。且这些模型或者模块的职责不能超越这个高层次思维概念的边界。
为什么要归纳？
其实是为了保证相近的职责模型聚拢在一起从而保证职责的高内聚，同时明确出来的两个子域的边界，保证模块和模块之间的低耦合。
对业务概念模型的归纳有助于做业务需求分析时判断高内聚和低耦合，而且在系统模型上，对系统模型进行分类也有助于做应用逻辑架构中模块的高内聚和低耦合，但是应用逻辑架构的不止高内聚和低耦合，还有其他让职责单一的方法，这些后面的章节会做介绍。
3.2.3 按职责来进行归纳
接下来我们来讲讲业务概念模型到业务概念架构判断方法：
1）通过名词定义来进行归纳思维概念
如果多个模型都在围绕某个名词，那么我们倾向将这个名词提炼出来。产品在设计时，基本上我们已经能够得一个粗略的业务模块划分，但是这个粗略的划分是不一定是合理：
一是有可能我们的理解是不到位的，导致用错了名词，这个我们前面的文章中也提到过了。
二是这个结果也只是一个粗略的结果，需要进一步精化。
2）通过内聚的度量公式来进行归纳
业务模型图中，模型和模型连线（连线就是模型和模型连接线）数量除以模型的梳理得到的值比较大的，那么我们可以看做是内聚，这些连线比较紧密我们趋向将其放到一个模块中，连线不是那么密切的，我们趋向于将它们放置在不同的模块中。然后我们再观察 连线数 / 模型数 观察内聚度量是高了还是低了，通过这样的方式归纳完成之后，我们再来通过度量公式来度量各模块的内聚和耦合程度。
3）其他归纳方式
如果我们划分出了基本模块，发现还有一些模型不确定应该放到哪些模块中，我们还可以使用创建者原则和信息专家原则来判断应该将该模型归纳如哪个模块。
比如说，对存储系统进行系统建模，表和字段的关系在业务概念模型中是1对n的关系（在系统模型中是组合关系，强生命周期依赖，但是这里我们还没有到讨论应用逻辑架构的时候，只是在推导业务概念架构），此时将字段放到另外一个模块显然不合适，原因是根据创建者原则。
当我们不清楚把字段模型放到哪个模块的时候，我们可以看看字段这个模型是由谁创建的。
根据这条原则显然这里是表创建了字段，没有表对象，就没有字段对象，所以根据这条原则，我们就倾向于把字段模型放到表所在的模块中。
重点：失去了最底层合理且正确的演绎，上层的归纳掌握的再好，也很难得出合理的结果。
我们来看看归纳之后的效果示意图：
图中的 A1，A2，A3，A4 之类是示意图，表示 A 模块内部还存在子模块，当然我们其实是先推导出子模块，然后对子模块再次进行高级别归纳，形成父模块。
父模块层级再进行归纳，就形成了祖父模块，或者再向上形成曾祖父模块等等。粒度越大的模块，一般都对应更大的组织，越存在跨团队沟通，所以划清边界的要求就越高。
3.3 业务流程
除了业务模型之外，业务流程也是我们需要总结并明确的地方，这个地方主要明确的就是边界和异常分支等等，尤其是异常分支非常重要，很多业务方案的设计中对异常分支的考量是不重复的，这需要工程师对业务方案提出挑战，以明确业务方案中的各种流程的异常分支。
3.4 业务概念架构总结
我们工作中常见的推导有两种方式，一种是自顶向下推导，一种是自底向上推导，显然，两种推导使用的方法是不一样的。细心的读者会发现，其实我们刚刚说的问题空间领域模型和边界分析这套方法就是自底向上的演绎和归纳方法。
四 基础逻辑架构推导（软件设计阶段）
前面我们讲到了业务分析阶段，也是问题空间建模和问题空间业务概念架构梳理，业务分析阶段和软件没有任何关系。但本文中它是软件设计的前置条件，没有 get 到点的同学，请务必再把前一章仔细阅读。
接下来我们来讲讲软件设计阶段我们需要产出的应用逻辑架构。
4.1 再谈逻辑架构特性
文章开头讲到了逻辑架构的相关特点，我们回顾一下：
- 应用逻辑架构的作用：我们把前面那个例子再搬过来：如果拿汽车举例，那就是发动机模块中包含了哪些子模块（活塞，曲轴，连杆，缸体，缸盖，等等）发动机模块和变速箱模块之间的关联关系是什么，和底盘的关联关系是什么，发动机，底盘，变速箱，电子系统在整辆汽车中的职责，关系，约束是什么。这些都是用来指导汽车研发的。而不是指导用户如何使用这辆汽车的。
- 目的：所以系统模型和应用逻辑架构都是用在软件设计阶段，其目的是用来指导软件的研发。
- 受众：逻辑架构的受众有哪些呢？一般是这些人：研发人员，各层级架构师，各层级技术管理者，总的来说他们都是架构的设计者和实现者。
这里还是请大家务必要跟产品功能架构区分开来，它们的受众和目标是不一样的。
4.2 基础逻辑架构的推导概要
在文章开头的图中，我们讲到应用逻辑架构来源于系统模型，数据模型，业务概念架构，还有流程，如下图所示。
接下来，我们分别从三个角度来阐述逻辑架构的生成：
- 业务概念架构
- 模型（系统模型和数据模型）
- 流程（系统调用流和数据流）
看到很多同学画的图没有区分出调用流和数据流，经常造成误解，造成沟通效率下降，甚至不能够准确的说明问题。所以在画图的时候，一定要注意区分调用流和数据流。
接下来就根据业务概念架构和系统模型及流程来推导一下应用架构（逻辑架构）。我们来看一下一个简单的逻辑架构构成的 gif 示意图：
从这张图中，我们可以看出应用逻辑架构是如何一步步被构成的，整个过程存在以下关键点：
1）在业务概念架构的基础上推演应用逻辑架构。
2）根据流程和系统模型来完善应用逻辑架构。
3）横向提炼模块的问题：要实现业务模块，需要什么非业务模块的支撑，比如监控，报警，配置等等，而这部分内容往往还是可复用的。在上述动画中，可以理解成移动到最右侧的部分，当然可以移动到左侧，只是动画中没有体现出来。
4）纵向提炼模块问题：有类似职责的模块在技术实现上是否可以提炼成可复用内容，提炼的结果可能是：
- 独立的服务复用，在上述动画中，可以理解成最下方。
- 或者二方库复用，在上述动画中，可以理解成最左或者最右侧。
- 等
5）还有一些模块是为了支撑性能或者稳定性的，并非是从业务概念模型提炼而来，如图中深蓝色的模块。
最终，出现的逻辑架构是分层的和分片的逻辑架构，下面我们来一步步阐述这个过程。
4.3 根据业务概念架构推演
业务概念架构图产出之后，基本上，我们逻辑架构的初步模型就具备了。所以我们可以理解成，第一步就是把业务概念架构直接先搬到应用逻辑架构中来，此处就不用多阐述了。
啰嗦两句：尤其是较为顶层的粗粒度业务架构，一个是自顶向下分解得来，一个是自底向上演绎和归纳得来。而自顶向下分解尤其考验人对业务的理解能力，如果对业务理解不透彻，那很难产出合理的粗粒度业务概念架构。
4.4 根据系统流程进行推演模块
当业务概念架构产出之后，逻辑架构的骨架初成，接下来就是在这个框架上去填充内容。第一步就是根据流程来进行模块划分。
总结一下，这里的方法就是，先根据业务流程，分解出系统时序图，根据时序图开始对模块进行归纳，从而得到粒度更大的模块。
这是粒度比较细的根据流程划分模块的案例，在粒度更大的流程，此方法同样适用，看大家是工作在何种粒度上。
通过流程来进行推导是我们日常工作必不可少的一部分，尤其当很多场景的流程具有业务共同点时，那么可以考虑提炼出这些业务共同点，以提升研发的效率。
4.5 非业务线系统根据流程推导模块案例
除了对流程进行归纳之外，我们还可以对系统模型进行归纳。我们知道，业务概念模型一般可以直接转换为系统模型，但是系统模型并不只是业务领域相关的模型，比如查询模型是一个经常出现的，这在 OLTP 的场景十分常见，而在 OLAP 的场景简直就是顶梁柱。非常常见的就是 SQL parser 模块，下图是 spark 体系中 SQL SQL 的主要流程和对应的模型，根据这个模型我们基本上也可以梳理出模块：
根据这个流程，我们发现了什么？我们发现了 spark 中是这样分模块的（这里面的模块已经落地成 package 了）：
所以说按照业务流程转换成的系统流程来推导模块是非常重要的手段。
除此之外需要还需要强调的是，流程和模块一样，也是有粒度的，相同粒度的流程节点放在一起才更加容易推导出合理的架构模块。至于什么叫相同粒度，请参考一下《金字塔原理》。
流程的粒度很重要，粒度粒度粒度，请重视流程的粒度。
4.6 根据性能 & 稳定性 & 成本等进行提炼模块
前面讲的都是从业务的角度来阐述架构的推导，接下来我们从计算机科学与技术的角度来阐述一下这些非功能性模块的推导，这里拿性能来举个例子吧。
数据分析的报表场景降低 RT 的方案
在一些数据分析产品中，绩效监控及报表展示是一个非常重要的场景，这个场景下的数据量是比较大的，为了降低 RT，我们不得不通过 ETL 对数据进行预计算，将原有的大表清洗成聚合之后的小表，以加快查询的速度。这样做的缺点是每次进行报表的修改，就要进行相关的ETL逻辑，高时间和人力成本，高性能。
为了把高时间和人力成本 & 高性能转换成低成本&高性能，我们需要把人工操作转换成自动操作，把 ETL 的过程去除。
第一个选择是将一个大表的数据存储到另外一个支持大数据下高性能的查询引擎，这样就极大的减少了 ETL 的操作，但是这样就带来一个问题，就是大数据量下把数据从 ODPS 导入到某个 ROLAP 的查询引擎中是比较耗时的，而且每次查询需要进行在海量数据中进行大量的 scan，但实际上获取的数据量并不大。这样的查询的 RT 依然需要亚秒级。
第二个选择是根据报表的定义，自动的将判断出用户需要查询什么结果，将查询结果提前计算出来，然后只把这些少量的预计算后的结果导入到 ROLAP 引擎中（具体请参考 apache 开源项目 Kylin）。然后在报表的场景下，查询的 RT 下降到了百毫秒级。
显然我们要实现第二种方式，这个时候在业务功能没有增加的情况下，我们必须要增加一个模块，在我们的产品中，我们称之为 intelligent cube，因为我们这里引入了机器学习算法对 cube 的构建进行了预测，无需或者只需非常少量的人为参与。
最后导致逻辑架构中有部分是来自业务概念架构推导而来，有部分是系统流程推导而来，有部分是因为性能 & 成本的需要产生的设计。
注意：理论上来讲，逻辑架构上需要指出模块之间的依赖关系，只是如果这样，不是特别美观，所以就根据上下和左右的位置来大概描述模块之间的关系了。
这两个案例基本可以说明，根据性能 & 成本 & 稳定性推导出来的模块也是逻辑架构组成的重要部分。
但是这个还只是一个场景一个场景来解决 RT 问题，虽然 icube 自己内部是有个体系的，但是通过这样的方式来解决 RT 问题对于整个架构来说也是自底向上构建的一个环节。在下一篇文章中，我们将会阐述相同的案例，但是思路是自顶向下来构建性能领域的体系化架构。同样一个事情，用不同的思路来做，对总目标的帮助是不一样的，而且两个方法是互补的，谁都少不了。
这样的模块是如何得来的呢？
看上去我们都已经知道了系统中有不少类似的纯技术相关的模块，但是这些模块内部是如何设计出来的呢？
一般来说有如下方法帮助我们做这些模块的内部设计：
1）调查业界的开源技术类产品中是否有类似功能的，比如预计算在业界有 kylin，而星环等专业大数据公司也都有自己的 cube 预计算产品。
2）查阅业界相关的论文，比如说在预计算领域就已经研究了几十年，计算机发展的不同阶段有不同的论文，网上一搜一大堆，不断研究，必对工作有帮助。
3）多关注业界的牛人，看看他们在想什么，说什么，参加参加相关的会议。
4）自己通过逻辑和数据结构 & 算法推导出来。
如果每次都只通过自己的逻辑和自己已经掌握的知识来进行方案的推导是不够的，一个是我们的技能有时候和事情是不匹配的，但是我们往往不知道这样的事实的存在，所以此时一定要虚心学习，请教他人，扩展自己的知识边界，才能做出更好的方案和技术决策。
4.7 应用逻辑架构推导小结
根据上文所述，基本上应用逻辑架构的推导有 4 个子路径，他们分别是：
- 业务概念架构：业务概念架构来自于业务概念模型和业务流程
- 系统模型：来自于业务概念模型
- 系统流程：来自业务流程
- 非功能性的系统支撑：来自对性能，稳定性，成本的需要
每个子路径中都存在相关的具体方法。
如果真的要想学习东西，而且想学的更快更深入，就要关注自己如何集中注意力，要思考自己的思考方式，研究自己的研究方式。
说明：以上是本文的上篇，关注阿里技术，后续我们将继续推出本文的下篇，继续讨论架构的基本约束、逻辑架构的复用以及逻辑架构分层的问题。