下载掌阅APP，畅读海量书库
立即打开
本章先简要概述架构认知框架，后续章节将详细阐述该框架中的3个维度。
在程序员成长为架构师的过程中，面临的第一个阶段是知识体系构建，需要学习众多且分散的架构知识点，涉及面向对象、DDD、TOGAF、敏捷、DevOps、中间件、微服务，以及高并发、高可用、可扩展等。
这些知识点之间似乎缺乏一条清晰的学习主线或关联关系。不过，有一点是非常明确的：所有架构知识都是为了软件系统开发服务的。因此，我们尝试从这个视角去推导架构知识的模型。
首先，软件是一个系统。按照系统的定义，所有系统都是由 元素、关系以及功能/目标 3个要素组成的。其中，元素代表“是什么”，功能或目标代表“干什么”，而关系则代表“怎么干”。
在软件系统研发过程中，我们通常先从客户侧获取需求，即目标系统的功能或目标，再通过架构设计反推出系统的组成元素以及元素之间的关系。
因此，简而言之，架构设计是由软件系统的“干什么”来推理出“是什么”和“怎么干”的过程，是一个由果到因的过程。架构设计的过程简化如图1-1所示。其中，“干什么”通过需求来获取，而“是什么”和“怎么干”则属于架构编排工作，至此可以初步得到一个架构知识模型。
图1-1 架构设计的过程简化
因为我们比较熟悉需求获取，所以这里暂且略过。架构编排中的“编排”一词非常类似于“组织”的动词形式。不过，“组织”一词更强调人与人之间的关系和互动，因此在本书中涉及社会或企业时将使用“组织”，而涉及架构时将使用“编排”。同时，笔者会用“组织”进行类比，以加深读者对架构编排的理解。对社会组织来说，它的运转核心是“实体+规则”，其中实体可以是人、公司等，规则负责将实体有序地组织起来。例如，家庭依赖亲情关系来组织，陌生人之间则依赖法律和道德来组织。
架构编排由“架构元素+架构规则”的二元组构成。架构元素可能是应用、服务器节点、限界上下文、类等，而架构规则负责将多个元素有序地编排在一起。例如，在DDD中，多个限界上下文按照一定的规则编排起来就形成了某一个领域或子领域；多个应用按照一定的规则编排起来就是应用架构的分层视图；多个服务器节点按照一定的规则编排起来可能就实现了高并发或者高可用；而多个类编排起来可能就形成了模块或DDD中的聚合等。
显然，需求获取和架构编排是架构设计的两个重要知识领域，但是它们所代表的知识均在某一个时间节点产生作用，是相对 静态的知识领域 。 在架构设计中还存在着另一类知识 ，从时间维度上看，它们需要跨越一定的时间周期才能发挥作用，例如敏捷、DevOps、持续集成、持续交付、迭代、重构、系统/模型的演进等，属于 动态的知识领域 。因此，在架构知识模型中，还需要加入 架构演进 这一概念。
再回头看“需求获取”这个概念。从定义上看，它属于一个单向过程。然而，在架构设计中，需求获取并不是单向的，而是需要多方通过充分沟通才能获得的。此外，在架构设计的各个阶段，需求还会映射到业务模型、应用模型、数据模型、技术模型、类图模型、活动模型等，即在架构设计的不同阶段，都涉及不同类型信息的沟通与获取，并转化成另一种信息（模型）之后传递给下一个阶段。
因此，在建立架构知识模型时，使用“ 信息交换 ”来替代“需求获取”更加合适。信息交换可以涵盖信息获取、信息沟通和信息传递等含义。总而言之，信息交换主要指的是在架构设计过程中，不同阶段信息的输入以及模型结果的转化、输出和传递等。所以，经过上述推导，我们最终得到了以下架构知识模型：
架构知识模型=信息交换+架构编排+架构演进
此外，软件系统研发的目的是什么？它一定是为了满足客户的需求而存在的。因此，接下来从客户对系统期望的角度出发，再来审视架构知识模型是否涵盖了重要的部分。
从客户侧考虑，对软件系统的期望通常包括以下几个主要方面：功能符合预期、低成本/交付速度快以及需求可修改。其中，功能符合预期主要是指信息交换方面。低成本/交付速度快对应的主要是架构编排，所以架构编排的本质是为了实现降本增效。而需求可修改对应的则主要是架构演进。
总体来说，将架构知识模型化主要带来两个好处：一是将架构知识分类后便于厘清知识边界；二是相同分类下的架构知识往往蕴含着相似或相同的规则，方便关联记忆。
例如，DDD中的限界上下文及其关系，应用架构中的应用及其关系，面向对象编程中的类之间的关系等，都属于架构编排范畴。虽然这些概念来自不同的领域，但是它们在拆分和交互时均采用了相似或者相同类型的规则，例如高内聚、低耦合等，在后面的章节也会讲到很多类似的案例。
架构落地方法指的是通过架构设计一步步实现一个系统的指导体系。业界目前已经有不少成熟的架构落地方法论，其中比较流行的有面向对象的RUP、面向领域的DDD和企业架构框架TOGAF等。下面先对它们进行简要介绍。
RUP（Rational Unified Process）是面向对象的软件开发方法，主要包括4个阶段和9个核心工作流，如图1-2所示。同时，它融合了现代软件开发中的许多最佳实践，例如迭代开发、需求管理、构件的使用、UML等。RUP的优势在于有一个完整的指导过程，缺点主要在于以用例作为驱动，无法解决复杂系统的开发问题。
图1-2 RUP软件开发方法
DDD是随微服务兴起的一个面向领域的软件开发方法，包括战略设计和战术设计两个阶段，如图1-3所示。
图1-3 DDD软件开发方法
DDD的优点在于它是以领域驱动的，可以解决复杂系统的开发难题。但是，DDD也存在以下一些缺点。
一是 重设计，轻过程 。DDD战略设计和战术设计过程只是通过概念串联在一起，并没有像RUP那样提供一个完整的过程指导。
二是 重概念，轻规则 。虽然DDD中提出了许多有用的概念，如领域、子领域、限界上下文、聚合根等，但在实践中缺乏明确的步骤或规则来推导出它们。
三是 重现在，轻过往 。相比DDD，面向对象不论是在需求分析方面还是编程方面，都已经是一个非常成熟的范式，并且积累了大量的最佳实践。许多人认为DDD难以掌握，其实主要原因在于没有很好地建立起DDD与面向对象之间的关联。如果可以利用好过往的面向对象的经验，学习DDD会轻松很多。
TOGAF是业界非常知名的一个企业架构框架，属于架构中的架构，它提供了一种专门用于设计企业架构的标准流程——架构开发方法ADM作为其核心，如图1-4所示。目前，国内大多数金融企业的架构方法论均源自TOGAF。它的优点在于具有一个完整全面的架构设计原则和过程，并且非常理论化，其缺点也主要在于过于理论化，直接应用会难以落地。
本书后面将要介绍的架构落地方法，并不是一个全新创造出来的方法，它是把RUP、DDD和TOGAF的内容裁剪、组合而成的。同时，读者不用担心之前是否有RUP、DDD或者TOGAF相关的学习经验，后面章节会深入介绍DDD和TOGAF，并且介绍时主要侧重于应用实践，不会涉及太多理论知识。
图1-5展示了将要介绍的架构落地方法，包括需求分析、架构设计、系统实现和系统维护四个阶段。通过这个方法，我们可以逐步设计出一个复杂的系统。
图1-4 TOGAF架构开发方法ADM的内容框架
图1-5 架构落地方法
在很多关于架构的学习资料中，架构思维模式的重要性经常被提及。简单来说，思维模式就是我们思考问题时所处的层级。架构设计毫无疑问是一项需要创造性的活动，许多问题往往需要架构师在不同的思维层级上进行灵活切换，以便从各个角度去加深对问题的了解，从而更透彻地理解问题，并通过架构设计来落地实现。
本书将架构思维模式大致分为三层。
第一层是 专业层 ，指的是架构师能够利用架构专业或领域提供的规则（通常表现为具体的技术），去解决架构设计问题。例如，DDD、面向对象、应用架构、数据架构，以及中间件技术都属于专业领域范畴。
第二层是 模型层 ，即架构师能够通过抽象出来的模型或模式解决同一类架构设计问题，例如上面提到的架构知识模型，以及后面将要介绍的价值模型、企业模型、TOGAF双飞轮模型等。
第三层是 本质层 ，即借助底层思维模式来洞察架构问题的本质，并运用跨学科知识综合解决问题。
程序员在成长为架构师的过程中，通常会在第二道关卡停滞不前，即便已经掌握了丰富的架构知识和架构落地方法，但在面对复杂系统的架构设计时仍然缺乏信心，或者需要频繁地对设计方案“打补丁”，甚至推倒重来。
实际上，架构的真正难点通常不在于技术层面，而在于理解业务的本质，并将业务问题与最适合的技术进行匹配上。因为技术往往只是问题界定后使用的工具，而我们更欠缺的是对问题的界定和对业务的整体性认知。因此，在遇到这个关卡时，我们需要注意思维能力方面的提高。
在专业、模型、本质这3个思维模式层次中，尽管每个层次都提供了一些解决问题的规则，但是规则的数量显然随着层级的降低而减少，专业层级的规则最多，而本质层级的规则最少。规则越少，呈现的力量反而越大。
事实上，我们都很熟悉现实世界中底层规则的力量。例如，在瓦特蒸汽机出现之前，人类数百万年来一直依靠体力劳动来获取生存所需的能量。然而，一旦“化石燃料可转化为动能”的规则被发现，人类就迅速进入工业革命时代，并开始以惊人的速度取得进步。这就是底层规则的力量。
因此，只有在思维模式上进行持续提升，我们才能更容易洞察业务和问题的本质，并在应对复杂系统的架构设计时游刃有余。
综上所述，我们得到了一个三维的架构认知框架，如图1-6所示。
图1-6 架构认知框架
在这个框架中，3个坐标轴的解释如下：
1） X 轴代表架构落地方法，包括需求分析、架构设计、系统实现和系统维护4个阶段。
2） Y 轴代表架构知识模型，它不仅仅用于架构知识分类，对架构落地方法的标准化同样作用很大。一般来说，架构落地方法的每个阶段的任务之间存在显著差异。然而，通过引入架构知识模型，可以将每个阶段的任务划分为信息交换、架构编排和架构演进三类。将不同阶段的任务名称一致化，其意义不仅仅在于方便记忆，更重要的是相同类型的任务意味着底层规则也基本一致，可以相互借鉴。
3） Z 轴代表架构思维模式，不同的层级代表着其规则蕴含着多大的力量，可以用来解决多大范围内的架构设计问题。
此外，在架构认知框架中，不论是架构知识模型、架构落地方法涵盖的4个阶段，还是架构思维模式都是相对固定的。然而，各个环节实际应用到的架构知识，可以在框架内部根据不同的系统需求或者技术更迭而动态变化。举个简单的例子，项目根据规模大小可以选择是否进行业务架构建模，编程语言可以选择Java或Python等。
接下来将详细介绍架构认知框架中的三部分。不过在此之前，先来探讨一下编程与架构之间的关系。这一点非常重要，因为绝大多数架构师是从程序员逐步成长而来的。然而，仍有不少程序员认为编程和架构是两个相对独立的知识领域，或者是知识逐级递进的关系。实际上，以上观点都是不正确的，那么它们到底是什么关系呢？
1.4节提出了一个架构认知框架，并简要介绍了它的推导过程。然而，可能有些程序员看过之后，对于能否掌握心存疑虑。有科学研究表明，如果一件事情可以和现有的知识建立起关联，则更容易被理解和掌握。因此，本节将讨论编程和架构之间的关系，以帮助大家更好地理解该框架。
我们先将架构设计和编程过程想象成一个黑盒，架构和编程的基本结构如图1-7所示。
图1-7 架构和编程的基本结构
可以发现，架构设计和编程的功能结构基本是相同的。因此，用和1.1节中一样的推导方式，不难得出一个编程的知识框架：
编程知识框架=信息交换+代码编排+代码演进
相比较而言，在信息交换方面，架构关注的是系统维度需求，而编程关注的则是模块维度需求；在编排方面，架构关注的是将子系统或微服务有序地组织起来，来实现业务功能；而代码编排关注的则是将各个模块或类有序地组织起来，来实现技术功能或某一局部的业务功能；在演进方面，架构演进和代码演进的源头均是业务需求的变更，只是架构演进更关注整体层面，而代码演进关注的是代码层面。
不难看出，架构更关注的是宏观层面，而编程更关注的则是微观层面。然而，由于两者之间知识模型的相似性，我们发现：不论是信息交换，还是编排和演进，它们所使用的规则都是基本一致的。举个常见的例子，编程领域的高内聚、低耦合等规则，在架构领域也同样适用。
此外，这两个领域的一些规则看似不相关，但是它们的底层规则实际上是相同的，这就表明可以通过底层规则将编程和架构联系到一起。例如，代码开发规则中的MVC和架构规则中的应用分层，本质上都是还原论思想的应用；代码开发规则中的异步响应请求和架构规则中的CAP原理，本质上都是升维模式的应用。第10章还将探讨大量类似的案例。
上面提到的编程和架构之间的关系是非常有用的。换句话说，我们建立起了编程和架构之间双向互通的桥梁，这个桥梁不仅有利于程序员利用已有的编程知识掌握架构知识，而且也可以深化架构师对编程的理解，两者之间可以形成一种螺旋上升的关系。
甚至可以这样说，优秀的架构师一定是优秀的程序员，而优秀的程序员也很容易成长为优秀的架构师。二者更像是宏观和微观的关系，宏观中包含着微观，而微观中也处处映射出宏观的样貌。
希望上面的阐述能够打消你的一些疑虑。作为程序员，无论你未来是否想成为架构师，学习架构知识对编程能力的提升都是极有帮助的。
本章提出了一个架构认知框架，它包括架构知识模型、架构落地方法和架构思维模式3个维度。其中，架构知识模型包括信息交换、架构编排和架构演进3个维度；架构落地方法包括需求分析、架构设计、系统实现和系统维护4个阶段；而架构思维模式包括专业层、模型层和本质层3个层次。此外，本章还探讨了编程和架构的关系。