架构设计的本质

做者 | 编程原理林振华

【问题】

• 什么是系统设计，系统设计的核心是什么？
• 如何训练系统设计的思惟模式？
• 有什么方法来帮助咱们理解复杂的系统？
• 如何进行系统分析？
• 架构设计的本质是什么？
• 如何进行架构设计？
• 如何进行业务领域建模？
• 模型如何推导出架构设计？
• 架构设计须要遵循哪些规范？

【关键词】

系统思惟，系统分析，系统设计，架构元素，架构视图，架构模型，业务模型，概念模型，系统模型，分析模型，设计模型，用例驱动，领域驱动，物件，功能，物件结构，功能交互，利益，架构工具，决策选择，架构师，架构图

全文概要

软件从业人员的成长路线大致是在管理线和技术线上造成突破，固然也有结合起来相得益彰的。而技术上的追求，架构师则是一个重要的门槛，对于刚入行的程序员可能会认为架构师就是画架构图的，诚然架构师很重要的一个职责是绘制架构图，但这只是其中一个很小的环节而已。

实际上架构也只是系统设计里面的一个重要环节，除了架构还包含了商业诉求，业务建模，系统分析，系统设计等重要领域。本文尝试从更高视角从新审视架构设计的工做，把架构设计的上升到系统设计的立体空间去探索，最终勾勒出系统设计的全域知识体系。

思惟分析

1. 系统总览

人类社会活动中的无论大大小小的，简单抑或复杂的事物，总要先出如今咱们的脑海里，而后再投射到现实的物理空间来。咱们老是在孜孜不倦地追求美好的事物，但现实存在的问题就是，首先咱们的脑壳也理解不了太过复杂的东西，其次脑海里的想象有时候也很难真实无损的映射成现实的系统，再者因为老是资源有限的，咱们并无花不完的预算。

归结起来设计一个系统，或者朴素的说，作一件事情，咱们须要解决如下问题：

在解决以上提出的问题前，首先声明咱们要实现的是一个系统，而不是随意混搭的一件物品，毕竟如今讨论的不是行为艺术。那么就须要先来了解系统的定义:

系统是由一组实体和实体之间关系构成的集合，其功能大于各个实体功能之和。

系统能够分为天然系统和人工系统，可是本文特指须要人类参与的人工系统。

天然系统：

• 人体系统
• 生态系统
• 大气系统
• 水源系统

人工系统：

• 机械系统
• 电子系统
• 操做系统
• 社会系统

2. 系统演化

上面谈到在系统设计流程主要是使用了分析思惟和系统思惟的结合，固然人类思惟还有其余的运做模式，好比批判思惟，创新思惟和发散思惟等，以此衍生的又是另一套大相径庭的方法论。下面咱们主要分析系统设计过程当中的思惟活动。

一般谈起架构师就会联想到各式各样的架构图，谈架构图就要搞清楚什么是架构设计，那么架构设计以前是什么呢？架构设计是整个系统建设的核心环节，犹如设计图纸之于建筑那么重要，那架构设计之上应该就是系统设计了。先搞清楚系统设计的定义：

系统设计是根据系统分析的结果，运用系统科学的思想和方法，设计出能最大限度知足所要求的目标系统的过程。

1）业务描述

上节弄清楚系统的概念，也就是先把边界框定下来，那么咱们要实现的无非就是以上类别的系统。天然系统是自然造成的，或者你愿意的话也能够认为是盘古开天辟地造成的，那也能够归为人为系统。我这么说的缘由是尝试把视角从软件这个领域往更加宏观的方向提高，让咱们暂时忘掉软件架构师这一根深蒂固的角色。

假设如今咱们想登上火星，言下之意是须要借助一套设备要把人类送到火星上，大胆一点，发挥仅存那点为数很少的物理知识储备，要设计出一套系统，可以把人类送到火星。这个时候老板就是愿意出资去火星豪华 7 日游的金主，那么须要一个负责人来实现这趟旅程，咱们姑且把这个负责人就称为登火旅行系统架构师（叫总设计师也行，不须要在乎这种细节）。那么这个系统架构师的工做，就是把登录火星的一系列需求和目标转化成为足于支撑登录火星庞大工程的系统架构。

根据系统总览提到的问题，先一一做答。

因为人命关天，这项工做看起来是挺复杂的，初次接到这个单子时我心里是彷徨的。可是回答了以上问题后，感受明朗了很多，咱们在完成系统性质，受众，利益和目标的分析和解答后，才能进入到系统的架构阶段。

首先对以上提到的需求，咱们先用动画片里面的简单画面为基础来描绘咱们的设计，而后大体根据能想到的过程完成初次业务流程的描述。

业务流程画图元素：火箭，机舱，地球，火星，来回，基础功能（安全，温馨，成本）

经过以上的描述，基本涵盖了火星旅程的四个阶段：登机，航行，下机游玩，返程，这本质上跟咱们平时搭个飞的去趟浪漫的土耳其也是差很少的。而在此以前咱们脑海里可能仍是一片混沌，沉溺在登录火星这项浩瀚的工程而不知道从而入手。

从混沌到开始有点头绪，其实无形中已经完成了一次建模，咱们称为业务建模。翻回去查阅系统总览的表格，其实咱们已经把需求这个维度大体列举出来了，把登录火星的几大领域给分离开来了。那么接下来就是要把登录火星这个项目的主线给说明清楚。

2）概念抽象

怎样把这件事的主线说明清楚？口若悬河的把一件事情讲完其实反而是很难讲明白，除非这件事情自己足够很是简单的。那么就须要抓重点的来讲，这个时候就须要一个叫作“概念”的工具。

概念是抽象的、广泛的想法，是充当指明实体、事件或关系的范畴或类的实体。

简单来讲，概念就是用简单的一个词汇，就可让在坐的你们都能准确无误的理解这个词汇所表达的含义。这个是语言独特的魅力，能够说有个概念这个武器，才有了人类屡次工业革命的文明大爆发。有了“概念”这个工具，再对概念进行组合，会爆发出无穷的生产力。

这里穿插讲一下概念的应用，比“傅立叶级数”这个概念，我敢打赌有 80% 的人不知道所谓何物，可是不要紧，咱们并非要来科普这个概念，先根据百度百科来看看这个概念的描述：

先不要怕，我这么说的目的不是为了让你们搞懂什么是傅立叶级数，这里咱们能够看出即便这么鬼畜概念也是很普通的基础概念元素组成的，好比收敛公式，好比三角函数，好比 Σ 求和概念，甚至像 1，2，3 这些阿拉伯数字。这里不得不说学数学最核心的环节就是深入理解概念，没有之一。

说回来，这里的语境就是在你们都共同理解接受这些基础概念后，通过一系列复杂组合的高级概念，也依然可以清晰严谨的表达出来，下面傅里叶级数的产生过程的动图看看就好。

好了，如今咱们知道了概念这个工具的重要性和功能，前面咱们已经列举了登录火星要作的事情，那么如今就须要精确简洁的把这件事给说清楚了，这个是个困难的任务，由于若是主线没有梳理清晰，后面整个工程将万劫不复。

在业务建模后就是概念建模，做为架构设计的输入，这个阶段就须要对核心业务的充分理解，同时在基础性和通用性方面的功能也须要同时考虑，这个阶段须要大量的业务专家和各个领域的科学家通力协做，保证对系统的理解没有误差。通过一系列的概念抽象和组合，最终输出登录火星工程的架构图，这里只是用于说明登录火星项目一样遵循这业务-概念-架构-设计的流程，不要在乎架构图自己合不合理。

3）系统落地

固然这还远远不够，系统之因此复杂，就是咱们对系统总有无数更多的要求，更多的功能，更好的性能，那么接下来就是对各个模块进行分析，细化，设计和实施。固然咱们不会班门弄斧真的在这里去分析登录火星的实际流程，以上这个例子虽然比较粗旷，可是基本也描绘了一个复杂系统建设的过程，也就是从需求，建模到架构的思惟过程，是从最原始的登火需求一步步扩展的过程。

其实咱们还能够举个小一点的案例，好比一个有趣的需求“赚钱”，引伸出来就是作一个能盈利商业项目架构，有兴趣的同窗能够根据这个思惟模式一步一步勾画出整个流程出来，相信这也是一个不错的方法，也许还真能解决些许困惑。下面演示的就是登月过程宏观层面落地的步骤。

3. 架构思惟

1）架构目标

一直以来我听过不少人在讲架构，有些人在作架构，可是很难讨论出一个你们都满意的定义，什么是架构师，架构师须要作哪些工做？或者说不多有往深的去思考，只知道被称为架构师说明这我的很厉害。在我毕业的时候有个同窗打趣的跟我说，大家作程序的无非就是增删改查，当时我竟无言以对，当时脑海里浮现的是一系列工具的应用技巧，好比 tomcat，nginx 的使用，还有对业务的翻译。

随着对业务的贴近和对计算机技术的进一步认识，我从新审视“这世上的系统无非就是增删改查”，这句话说对也对也不对，这句话就跟计算机软件无非就是 0 和 1 的集合，也对也不对。特别是对刚入行的人可能以为设计离本身比较远，由于习惯了打开 idea 才开始考虑业务，写代码才开始思考领域模型，这是很是很差的习惯，好像若是没有在 coding 状态下是没法进行建模思考，这个很难，须要持久的训练才能达成设计阶段进行思考。

架构设计只是系统设计里面的一个阶段，而系统设计是应用建设里面的核心环节，有一些简单的应用建设是不须要系统设计的，固然有一些复杂的应用，在能力超强的工程师团队，有足够的默契后，也能够直接进行建设。

软件架构之道最核心的问题是解决复杂性的问题，而且在解决问题的过程当中找到最佳的平衡点，既要简单又能知足发展。描述系统设计的本质，就是实现纵向上的时间，横向上的空间进行考虑，规划出决策路径，最终拿到目标结果。

架构师眼里第一件事不是多流行的技术，多高性能的框架，或者多完善的业务模型，而应该聚焦在利益之上。对，这个可能会颠覆一些认知，当咱们真正把利益放在首位后，再去考虑接下来要完成的事情，咱们的工做才能称得上架构。也就是说，架构师的天职就是最大限度地实现客户的利益，这里的客户能够是市场客户，也能够是协做团队，还能够是同一个团队的项目成员。

再直白的说，架构师就是负责把老板画的饼给实现了，在至关长的一段时间内保证产物有足够的利益回报。有人会说那咱们作的就是公益项目，就不考虑利益，我补充一下，这里说的利益不止是经济收益，还有系统带来的社会价值。那么又有人会说，架构是追求利益回报，那老板的目标就是炒股发大财，请架构师你给我选几支股票吧，那我会说其实优秀的基金经理也能够称为广义上的架构师。

2）架构过程

天然在增熵，而系统架构过程其实就是减熵的过程，一个架构的诞生始于目标的确立，而后是对需求的刻画，继而是落地方法的抉择。

所谓条条大路通罗马，有的是一路平川而有的则是崎岖不平，那么架构过程就是不断归类合并同类项，力求最合适的决策选择来实现咱们所要达成的愿望。在面对复杂业务的场景下，咱们须要作出以下的思考：

• 肯定系统实体对象和预期功能
• 抽象系统实体之间的关系，功能与实体的关系
• 划定系统的边界和外部环境的关系
• 预测系统带来的效果

在架构过程当中，很重要的一项任务就是识别系统的实体关系和功能关系，进而对系统效果进行预测，也就是在完成一系列的分析建模工做后推导出来的系统架构须要在预测上达到咱们要的效果，那么系统预测一般有以下四种方式：

• 经验
• 实验
• 建模
• 推理

3）系统思惟

系统思惟不等于系统化思考，与系统思惟并列的能够是批判思惟，分析思惟，创新思惟，而咱们追求的是元认知，也便是认识到本身处于何种思惟模式。系统思惟目标：

• 理解系统是什么
• 预测系统的走向
• 为决策提供知识支持

系统思惟首先是高效地理解分析现存的系统，对系统重构作好理论指导基础。

这一节介绍了设计一个系统须要经历哪些重要的环节，而且强调了谋求利益是系统设计的核心诉求。而后经过登录火星这项任务把一个庞大的工程变成了可理解的独立步骤，而且还有模有样的画出了架构图，体现了对业务建模到架构输出的流程。下面章节咱们将会展开来介绍一套核心的方法论，如何破局系统架构设计。

系统分析

上一节谈论了系统设计的心智模型和投射到物理世界的演化规律，但前提是创建在已经具有丰富系统设计经验基础上。而在进行系统架构以前，须要先对系统分析有必定的理解，比如咱们制造发动机以前，得先把发动机拆下来好好研究一番，直接上来就要设计出发动机有点像空中楼阁。

本节将提供一套基础的方法，来对现有系统进行分析，得出一些系统架构相关的推论。按照惯例须要先搞清楚系统分析的概念：

系统分析，旨在研究特定系统结构中各部分的相互做用，系统的对外接口与界面，以及该系统总体的行为、功能和局限，从而为系统将来的变迁与有关决策提供参考和依据。系统分析的常常目标之一，在于改善决策过程及系统性能，以期达到系统的总体最优。

大到银河系，小至原子粒子都有着特有的结构，何谓结构：

结构是指在一个系统或者材料之中，互相关联的元素的排列、组织关系。

而系统在物质世界里面固然也遵循这样的规则，分析系统跟分析银河系也同样，须要对它的组成元素和元素之间的关系进行分析。而对系统的分解也是讲究方法的，能够参考如下总结的一些方向：

• 体系概括
• 层级分解
• 逻辑关系
• 自顶向下
• 自底向上
• 由外向内
• 由内而外

1. 实体分析

实体指系统物理时空存在的单元，彼此经过必定的结构造成系统，那么在分析实体以前，咱们能够带着下面的问题进行分析：

• 系统是什么？
• 构成系统的元素有哪些？
• 系统元素之间的结构是什么？
• 系统的边界在哪里？
• 系统的使用场景是什么？

实体是系统的一项基础属性，是系统的物理体现或信息体现。对功能的执行起工具性做用，而描述实体一般能够使用如下工具来表达：

• 文字描述
• 符号描述
• 插图
• 插画
• 示意图
• 三维图
• 透视图

实体之间的关系就是结构，分析结构时须要对实体进行分解，实体能够建模为对象及其之间的结构，进一步能够分解为小的实体，又能够聚合起来称为系统自己，对实体之间的各类结构分析则能够得出系统架构，便是把功能元素组合成物理块时所用的编排方式。

1）分析实体

• 对实体的载体进行抽象聚类，造成对象，体现出边界
• 用适当的层次来分解架构的实体

2）分析关系

便是实体的结构，是对象之间存在稳定关系，有助于功能交互的执行系统实体有以下关系：

• 空间拓扑关系
• 链接性关系
• 地址关系
• 顺序关系
• 成员关系
• 全部权关系
• 人际关系

2. 功能分析

上面一节咱们了解了系统的物理基础，对组成系统的实体进行分解，分析，进而对实体的关系描述为结构，结构抽象是得出架构的基础步骤，而系统物理基础存在的理由是为了实现咱们的诉求，也便是系统的功能。毕竟万物皆有因，存在即合理，系统构建最终也是要达成咱们的意愿，完成这个诉求才算是合格的架构。分析形式相对来讲毕竟简单，毕竟实体是有形的便于理解，而功能则是由实体组合涌现出来的属性，功能分析过程须要跟实体不断的交互穿插。

关于系统功能其实能够朴素的认为就是动宾短语的集合，功能=动词+宾语，含义就是实体状态变化的过程，就是功能的体现，具体分析下文会详细展开。功能 = 主体 + 操做 + 操做对象，好比嘴巴有“吃饭”功能，飞机有“搭载乘客”功能，报表平台有“展现报表”功能。

• 操做：对象经历的一种转换模式，过程设计操做数的状态变化；

• 操做对象：操做数是一个对象，在某段时间内稳定且无条件存在，操做数不须要先于功能的执行而存在，操做数可能会由功能中的过程部分来建立，修改或消耗。

总结起来，系统分析就是创建一套方法论，去分析复杂的系统，令系统再也不那么难懂。

系统设计

通过了上几节的思惟训练和系统逆向分析，咱们也大概理解了系统设计的流程和系统架构的造成过程，本节将介绍系统设计，包括设计工具，需求分析，模型创建，架构推导，设计规范完整的系统设计流程。

系统设计，即设计出一套良好的系统架构，就是构建一套具有必要复杂度又不难懂的系统。下面在介绍方法论的同时，同时会穿插一个数据平台的大体设计过程。

在进入本章节系统设计前，咱们先要来学习学习一个架构 TOGAF：

TOGAF：框架开放组体系结构框架（The Open Group Architecture Framework，缩写：TOGAF）是一个企业架构框架，它提供了一种设计，规划，实施和管理企业信息技术架构的方法。TOGAF 是一种高层设计方法。它一般被建模为四个级别：业务，应用程序，数据，和技术。

在 TOGAF 中，任何一种企业能力的建设都须要对以下四种领域进行设计，包括针对这一可持续性架构实践建设：

• 业务架构：突出了架构治理、架构流程、架构组织结构、架构信息需求以及架构产品等方面；
• 数据架构：定义了组织中架构连续体和架构资源库的结构；
• 应用架构：描述了用于支持此可持续架构实践的功能和服务；
• 技术架构：描述了架构实践中用于支持各架构应用和企业连续体的基础设施需求和部署方式。

TOGAF 架构框架是一组工具，可用于开发各类不一样的架构：

• 描述了一种用于根据一组构建块来定义信息系统的方法
• 展现构建块如何组合在一块儿
• 包含一组工具
• 提供共同的词聚集合
• 包括推荐标准列表
• 包括可用于实现构建块的兼容产品列表

企业能够经过应用企业架构开发方法（ADM）来建设各类业务能力，下面咱们再来介绍另一种系统设计的思路。

1. 设计工具

工欲善其事，必先利其器。前文讲到思惟分析，不一样思惟模式决定不一样的方法论，那么在分析思惟层面，人类大脑其实很难理解太过复杂的东西，这个时候就须要借助一些工具来协助思惟的活动。

首先第一工具固然是语言，这个不用多说，没有语言做为基础将步履维艰，单个体的时候语言用于描述系统的诉求，而多个体的时候语言则扮演着沟通的角色，可是若是语言不互通的话可能就像鸡同鸭讲。即便是同一种语言，不一样的表述都会造成很大的误差，那么就须要一种广泛承认的统一语言，在系统分析审计领域，咱们首推统一建模语言（英语：Unified Modeling Language，缩写 UML），固然还有其余好比 SYSML 或者 OPM，下面咱们先大体介绍下 UML，列出 UML 的核心语言元素，视图，模型和过程。

1）核心元素

• 参与者
• 用例
• 边界
• 业务实体
• 包
• 分析类
• 设计类
• 关系
• 组件
• 节点

2）核心视图

静态图包括：

• 用例图
• 类图
• 包图

动态图包括：

• 活动图
• 状态图
• 时序图
• 协做图
• 泳道图

3）核心模型

• 业务用例模型
• 概念用例模型
• 系统用例模型
• 业务领域模型
• 系统分析模型
• 系统设计模型
• 系统组件模型

4）核心流程

• 业务建模
• 系统建模
• 模型分析
• 模型实施

5）软件工具

• draw.io
• StarUML
• Visual Paradigm

2. 需求分析

本节不打算讲需求分析师的工做流程，由于咱们已经很熟悉需求分析师对需求的分析过程了，因此无需多言，在讲需求以前咱们先来看看架构师须要完成的工做。

架构师并非全能的通才，没法了解全部细致的需求，因此架构师要作的就是简化系统的复杂度，消除业务歧义，致力于输出健壮兼容的系统架构。因为系统需求分析须要由架构师这个角色全程参与，深度理解业务，下面咱们简单对架构师角色进行讨论。

1）架构角色

咱们先看看传统系统设计两大核心角色的定义：

系统架构师：是在信息系统研发中，负责依据需求来肯定主要的技术选择、设计系统的主体框架结构，并负责搭建实施的人。

系统分析师：是在信息系统研发中，负责经过需求分析确认系统的需求，并进而造成系统产品设计的人。一般他们也会涉及可行性评估、项目管理、开发前评估、需求验证等工做。

传统意义的系统开发分为系统架构师和系统分析师两个角色，可是随着互联网的快速发展，现在系统建设愈来愈趋向于将两个角色结合起来，那么互联网时代架构师有以下职责：

• 了解问题领域，消除歧义
• 树立业务目标，抽象业务用例
• 完成涉众分析，发现系统主要受益者
• 划清系统边界，确立对外交互方式
• 划分优先级别，聚焦系统核心诉求
• 分析业务需求，输出业务模型
• 抽象业务概念，输出概念模型
• 推导系统架构，输出架构模型
• 负责技术选型，完成系统落地

架构师是软件开发活动中的众多角色之一，它多是一我的、一个小组，也多是一个团队，咱们分析的是架构师这个角色，能胜任这个角色的才是架构师，那么在这个角色上能作得更加出色的就是好的架构师。

以上架构师职责是总体上的描述，在细分领域有不一样的分类。微软对架构师有一个分类参考，咱们参考一下，他们把架构师分为 4 种：

• 企业架构师 EA(Enterprise Architect)
• 基础结构架构师 IA(Infrastructure Architect)
• 特定技术架构 TSA(Technology-Specific Architect)
• 解决方案架构师 SA (Solution Architect)

既然对架构师角色有诸多要求，那么也能够来概括一下架构师必备的一些技能，能力模型能够参考《职业成长的逻辑模型》一文中对能力模型的描述，架构师能力要求：

• 现有资源评估盘点及资源编排能力
• 消除歧义分清问题主次能力
• 业务简化描述，用例抽象思惟
• 通用市场法务市场领域基础常识
• 业务分析架构推导能力
• 计算机基础理论知识体系
• 通用技术栈原理认知
• 工具使用熟练，排查定位问题能力
• 技术深度广度
• 分布式高并发性能调优技能
• 产品思惟

2）利益分析

首先固然是要确立好客户，所谓客户第一，听起来很简单，若是只是单一的服务好客户，那确实不算很难。难的是若是同时存在多个业务方向的客户，并且客户直接的利益产生交集，并且存在矛盾，怎么权衡好利益分配，区分客户利益优先级，才是困难的。

不忘初心这一点尤其可贵，不少项目作着作着就偏离了当初的目标，这个过程咱们必定要牢牢抓住系统最重要的受益者，梳理好系统众多涉众的利益分配。

3）资源评估

资源评估不只仅是项目经理的事，并且仍是对团队资源的评估和编排，好比某项业务技术团队中研发和数据人员的配比，决定了数据平台投入的资源范围，这要求架构师在作设计分析的时候须要充分考虑到资源的利用效率，包括人力资源和机器等资源。

4）需求规范

用户的诉求体现为需求的输出过程，不一样层次分解需求得出了不一样的复杂度，咱们知道架构师的一项重要职责就是消除歧义，精准的把握需求来匹配用户的诉求。那么就须要一系列规范来保障需求采集的过程当中不失真。

下面列出了需求采集过程的一些指导原则：

• 每一个软件需求是否都有惟一的标识符？
• 每一个软件需求均可以验证吗？（若是可能，是否可正规化，量化）
• 是否对每一个软件要求进行了优先排序？
• 全部不稳定的软件要求是否都已标明？
• 软件需求是否完整？（涵盖了全部用户要求，考虑了全部相关的输入状况）
• 软件要求是否一致？
• 是否明确指出了软件需求之间的重叠交叉？
• 是否明确规定了初始系统状态？
• 软件需求是否表达了逻辑模型， 而不是实现形式？
• 软件需求是否以结构化的方式表示为抽象层次？
• 是否足够清楚，逻辑模型的结构
• 软件要求是否已正式形式化？
• 是否已证实软件需求的关键属性？
• 全部形式化的图表材料是否都随附了充足解释性文字？
• 是否针对项目团队缺少经验的领域描述了探索性原型？

5）需求描述

在进行需求描述时，咱们能够从多个角度来审视需求是否合理地表达出来：

• 知足需求，能带来什么价值，符合什么利益诉求？
• 需求没法知足时，会带来什么危害，有何潜在风险？
• 需求是否紧迫，必须在什么时间段内完成？
• 多个需求直接是否产生耦合，完成一个需求后是否带来了新的问题？
• 是否能多个备选方案来完成需求？

6）需求采集

回到咱们平台设计的案例上，通过用户访谈粗略的采集的需求：

• 单项业务壁垒是个困局，本质上是功能缺陷，打通数据壁垒 • 业务各个阶段的数据管理，要对数据底层进行管理 • 须要对由相同特性的报表实现快捷地生成

需求背后：

• 能够一次性看更多的数据 • 能够方便的切换数据 • 能够更快的看到数据

so，这个真的是客户想要的吗？总体上，用户想看什么数据？同时我也在思考下面的问题：

• 深刻分析用户需求
• 搞清楚咱们的客户是谁？
• 定义好问题，搞清楚问题的本质，分析问题矛盾之处，咱们要解决什么问题？
• 咱们要在多大范围内去解决问题，要解决跨度多长时间可预计的问题？
• 咱们的边界在哪里？
• 咱们的使命是什么？有了使命后再谈咱们本身，愿景是什么？

3. 模型创建

在系统设计这个阶段，咱们已经介绍了如何运用工具，还有用户需求的管理，接下来就是要把需求“消化”成咱们须要的架构。可是架构不是无缘无故就产生的，前文咱们用登录火星的案例也大概描述了系统的建设过程，那么在推导出架构以前，把用户不那么清晰的诉求转化成严谨的业务概念模型就颇有必要了。

1）模型基础

首先咱们要搞清楚模型相关的概念：

模型：是指用一个较为简单的东西来表明另外一个东西。

科学模型：是科学研究中对一类研究方法的通称，使用数学公式、电脑模拟或简单的图示来表示一个简化的天然界，透过度析这个模型，以期可以进一步了解科学，包括说明、验证假说、或分析资料。

概念模型：是用一组概念来描述一个系统，或用任何代替的形式来描述一个概念，以期能进一步了解或说明事物的运做原理。具体的形式可能包括思想实验、数学模型、电脑模拟、示意图、比例模型等。

业务建模：是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。

2）建模目标

便是说业务建模是一种建模方法的集合，目的是对业务进行建模。这方面的工做包括了对业务流程建模，对业务组织建模，改进业务流程，领域建模等方面。针对复杂难懂的系统，咱们构造出一个比较简单的模型，来表明复杂的业务，这个是一种有效的办法，这也是咱们须要建模的缘由，随着计算机的飞速发展，或许之后计算机能够帮人类承当一部分的设计工做，而计算机是不怕复杂业务的，也许那个时候就再也不须要这种特意适应人类思考的模型了。

创建模型不是最终目的，而是把复杂的业务诉求构建成简单的业务概念，在软件开发团队沟经过程中能造成共识，消除歧义，并且信息传递不失真，为输出架构奠基基础。

3）模型分类

在业务不一样的阶段，一般会使用不用的模型来表达，通常状况下咱们把模型分为：

• 业务模型
• 概念模型
• 系统模型
• 分析模型
• 设计模型
• 物理模型

4）建模方法

建模有不少种方法，对于一样的问题域使用不一样的建模手段，获得的模型可能也不尽相同。建模是一种对现实事件的抽象，不一样的心智会产生不一样的模型，好比宗教，不一样宗教就是对人生观世界观产生不一样的模型，咱们先介绍经常使用的建模方法：

• 领域驱动（DDD）
• 用例驱动（UDD）
• 四色建模
• CRC建模
• CQRS建模

下面咱们以用例驱动和领域驱动为案例来介绍这两种思惟方式的建模过程。

5）用例驱动

用例驱动是一种由外而内，先招式后内功的思想。咱们先从涉众对系统的指望开始，定义出系统如何知足他们的愿望。这一过程是感性的、外在的、符合当前需求的。

用例驱动的结果是咱们的软件是以实现一个个场景为目的的，认为当一个系统的行为知足了全部涉众的指望以后，即知足了涉众使用系统的场景以后，该系统就是一个成功的系统。

【创建用例】

用例定义：工具—>过程—>操做数 （主 谓 宾）

• 参与者：某些具备行为的事物，能够是人，计算机系统或组织；
• 场景：参与者和系统之间的一系列特定的活动和交互；
• 用例：一组相关的成功和失败的场景集合，用来描述参与者如何使用系统来实现目标。

【用例规范】

用例其实就是对一件独立事情的描述，这很是符合咱们人类语言的表达过程，咱们平常沟通很大部分是陈述一个观点，那就是以主谓宾的方式来表达，一样的编写用例也能够遵循这个结构。

【建模过程】

• 用例模型

用例：每一个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁能够用系统作什么，从而得到一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。

用例模型：用例模型是系统既定功能及系统环境的模型，它能够做为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工做流程的结果，可看成分析设计工做流程以及测试工做流程的输入使用。

用例有严格的规范，回顾上文系统分析里面，咱们对系统功能分析给出一个公式：功能 = 主体 + 操做 + 操做对象。用例也是须要这样的结构，好比“我爱你”是完整的用例，能完整的描述一件事情，而“爱你”则不能称为一个用例。因此用例模型创建阶段就要力求把用户诉求都完整的以用例表达出来。

• 业务模型

业务模型：业务模型采用业务用例来绘制，表达业务的观点。

咱们在数据平台对用例模型进行抽象。

**分析师 **为客户 制做 业务 报表：

抽象起来就是分析师制做报表，这个是咱们最朴素的模型，咱们以这个最原始最核心的用例为立足点点开始发散。

• 主语：分析师
• 状语：客户
• 谓语：制做
• 定语：某一项业务
• 宾语：报表

通过咱们对语言的分析，已经很清晰地呈现出咱们的业务模型，就是分析师制做报表，加上状语和定语的修饰，咱们知道是为客户这个主体建立的报表，并且是特定领域的报表，状语就是跟分析师强相关的。

• 概念模型

概念模型：概念模型是一种或多或少的形式化描述，描述的内容包括创建软件组件时，所用到的算法、架构、假设与底层约束。这一般是对实际的简化描述，包括必定程度的抽象，显式或隐式地按照头脑中的确切使用方式进行构建。

如今咱们明确了业务模型后，接着就是细化用户，补充更多的细节：

• 分析师 为 不一样的客户  制做  不一样业务的 报表
• 分析师 为 不一样的客户  制做  几款业务的 报表
• 分析师 为 不一样的客户  制做  一项业务不一样区域的 报表
• 两个分析师 为 某个群体用户  制做  业务线的 报表
• 客户 受权 某个群体  查看  不一样业务的 报表

结合咱们对业务的了解，能够丰富领域的属性，还有一个隐性的“权限”名词，咱们须要独立出来，由于权限不属于任何一个领域。

一般咱们须要角色概念来管理用户访问报表的权限。

• 管理员 为 不一样的客户  建立  一项业务不一样区域的 角色

• 管理员 为 不一样的客户  分配  一项业务不一样区域的 角色

• 小二 为不一样报表  建立  不一样  权限

• 系统模型

系统模型：系统模型是一个系统某一方面本质属性的描述，它以某种肯定的形式（如文字、符号、图表、实物、数学公式等）提供关于该系统的知识。

丰富业务场景后，总体的用例以下图：

• 分析师 为 不一样的客户  制做  不一样业务的 报表
• 工程师 为制做 个性  报表
• 小二 给不一样业务建立报表模板 来生成报表
• 小二建立权限 来 匹配报表
• 客户建立角色
• 客户分配角色
• 客户筛选人群进行营销活动
• 前置条件：业务告警？

6）领域驱动

用例驱动是一种从局部到全体的思惟方式，刚刚接触某一行业的人员从零开始来了解业务，复杂业务很难一开始就拥有上帝视角来分析业务。而领域驱动则是一开始就站在上帝视角来着手业务，领域驱动要求化整为零，它是一种由内而外，先内功后招式的思想。它要求团队里有资深的业务领域专家，该专家对业务领域极其了解，不但要了解其然，还要理解其因此然，或者是可以跟领域专业人员学习到足够的领域知识。

在此条件下，团队将从业务领域里找出反映业务本质的那些事物、规则和结构，把它抽象化，描述业务运行的基本原理和业务交互的机制，识别出用户的首要利益。

领域驱动须要领域专家深度参与，访谈专家，才可能得出领域模型，单靠技术人员自己很可贵出完成得领域模型。语言就是承载思想或者想法的模型，不一样的语言建模出不一样的思想，中西语言差别造就思惟差别，因此领域模型须要从语言谈起，用语言描述事物。领域模型本质上传递的是概念，是知识性的信息，语言正是让知识传递成为可能。

对于软件开发的场景来讲，把这些知识显式化，能快速对齐不一样角色、不一样参与方之间的概念，加速沟通，避免误解。

【领域模型】

咱们先得搞清楚领域模型的概念，而后才有领域驱动。

领域模型是采用业务对象创建起来的一种模型，咱们把领域模型当中使用到的业务对象称为领域类。

回顾咱们学了不少年的面向对象变成设计，而实际上真正使用面向对象开发的思惟倒是比较稀少的，好比传统 MVC 架构下的 web 开发，基本是失血模型的对象，让咱们不多真正使用面向对象来实现咱们的业务。而正是由于缺乏面向对象的业务实现的必要训练，让很人使用领域驱动时以为困难重重，这就须要咱们对领域模型有一些基本的认识，而后在训练中来深化对领域模型，面向对象的认识。

领域模型的核心思想是对象，而领域驱动的核心是分层，须要对实现架构进行分层，不一样的团队，不一样业务可能会有相应不一样的分层，可是总体上分层的思想就是解耦，把复杂的事情分解开来简单化处理。

传统架构挂着面向对象的名号，实际上干的全是面向过程的勾当，用户界面，数据库操做以及其余辅助性代码进程被写到业务对象里面，缘由就是能让业务快速的跑起来，而领域驱动则打破了这个传统，给出了通用的架构解决方案，包含 4 个概念层：

将应用按层分离而且创建好约束的交互规则是颇有必要的，代码若是没有被放在正确的位置上，则很快会发生混乱。领域层最核心的职责只应该关心领域方面的业务问题，基础设施则只需关心底层的数据交互和外界的数据通信交换，而无需关注业务的实现。

代码层面上各层的实现职责以下：

• 接口层：该层包含与其余系统进行交互的接口与通讯设施，在多数应用里，该层可能提供包括 Web Services、RMI 或 Rest 等在内的一种或多种通讯接口，该层主要由 Facade、DTO 和 Assembler 三类组件构成；

• 应用层：Application 层包含的组件就是 Service，在领域驱动设计的架构里，Service 的组织粒度和接口设计依据与传统 Transaction Script 风格的 Service 是一致的，可是二者的实现却有着质的区别，TransactionScript 风格的 Service 是实现业务逻辑的主要场所，所以每每很是厚重；而在领域驱动设计的架构里，Application 是很是“薄”的一层，全部的 Service 只负责协调并委派业务逻辑给领域对象进行处理，其自己不真正实现业务逻辑，绝大部分的业务逻辑都由领域对象承载和实现了，这是区别系统是 Transaction Script 架构仍是 Domain Model 架构的重要标志；

• 领域层：Domain 层是整个系统的核心层，该层维护一个使用面向对象技术实现的领域模型，几乎所有的业务逻辑会在该层实现，Domain 层包含 Entity（实体）、ValueObject(值对象)、Domain Event（领域事件）和 Repository（仓储）等多种重要的领域组件；

• 基础设施层：做为基础设施层，Infrastructure 为 Interfaces、Application 和 Domain 三层提供支撑，全部与具体平台、框架相关的实现会在 Infrastructure 中提供，避免三层特别是 Domain 层掺杂进这些实现，从而“污染”领域模型，Infrastructure 中最多见的一类设施是对象持久化的具体实现。

【建模过程】

有了领域建模的基础知识后，下面咱们介绍下领域建模的过程。

• 用户访谈：充分贴合业务，基于现有人员资源能力；

• 领域知识：首先咱们分析项目在领域分层后的概念项目涉及到：

  • 名词：分析师，工程师，客户，小二
  • 报表，报表模板，权限，角色，告警，人群，活动，决策
  • 动词：登录，建立权限，匹配权限，受权，建表，圈人，营销
  • 实体：报表，报表模板，权限，角色，人群，活动，决策
  • 值对象：告警
  • 服务：登录，建立权限，报表匹配权限，受权给用户，建立报表，圈人，营销
  • 模块：报表域，权限域，洞察域，营销域
  • 聚合根：报表（报表模板，报表数据），权限（权限，角色），活动（人群，营销规则）
  • 工厂：报表模板工厂，人群工厂，决策工厂，权限工厂
  • 资源库：数据库，消息，外部接口

• 领域模型：通过对领域知识的消化，就能够输出领域模型图。

4. 架构推导

通过了漫长的前戏--模型创建，本篇终于到了架构设计了，真的不容易啊。一开始我老是在纠结架构师应该输出什么架构图，什么才是标准的架构图，可是当我理解什么是架构，架构造成的过程后，我再也不纠结了，架构存在每个阶段，以不一样的形态出现，业务，产品，技术，实施不一样的阶段都须要一张提纲挈领的架构图来指导系统建设。

系统架构这个词常常放在一块儿说，以致于咱们以为天经地义，常常混为一谈。系统指的是由一堆实体组成的一个具有某些功能的总体，而架构则是架和构，便是框架和结构，也就是具有稳定诉求并且是能够支撑总体的组件。系统能够没有架构，好比咱们乱糟糟的系统。可是系统同时也是须要架构的，架构就像是系统的 DNA，架构决定了系统的走向和生命周期，好的架构能够支撑系统持久运行和更新迭代。

1）架构定义

咱们先来对架构进行定义：

架构：对系统中实体与实体之间的关系进行抽象的描述，用于指导软件系统各个方面的设计。

2）架构分类

随着互联网的发展，应用从单体到分布式，到现在基础设施的变革，咱们迎来了云原生时代，系统的架构随着基础技术的突破也不断演化，单体应用最简单最多见的架构就是分层架构，好比咱们熟悉的 MVC 架构，因为业务发展到必定层度后，须要对服务进行解耦，进而把一个单一的大系统按逻辑拆分红不一样的子系统，经过服务接口来通信，面向服务的设计模式，最终须要总线集成服务，并且大部分时候还共享数据库，出现单点故障的时候会致使总线层面的故障，更进一步可能会把数据库拖垮，因此才有了更加独立的设计方案的出现。

随着分布式技术的成熟，微服务架构开始大行其道，在此基础上的边车服务和 servicemesh 也开始进入蓬勃发展期，总体上架构有以下分类：

• 分层架构：MCV，六边形架构，洋葱架构
• 事件驱动架构
• 微核架构
• 微服务架构
• 云原生架构

3）推导架构

先问题，后定位，即：先使命后愿景，解决什么问题？先定义问题，何为问题，有矛盾即存在问题，专业的抽象和架构知识，以及背后的概括和演绎的逻辑思考方法，加上丰富的业务用例，经过逻辑排列，造成业务架构，首先咱们会用如下的表格来描述问题。

• 演绎

  • 将用例进行抽象分类成为业务模型
  • 将业务模型进行 IT 层面的思考，增长非功能性的组件造成系统模型

• 概括

  • 将用例以及问题进行分类聚合
  • 业务用例造成系统架构过程须要进行概括
  • 对行为稳定性，性能考虑的总结，概括为通用组件

4）架构输出

• 方案概述：对设计方案的归纳性描述；
• 设计约束：包括要遵循的标准或规范，技术上依赖的假设条件等；
• 技术选型：包括系统运行的软硬件环境，研发、测试的软硬件环境，编程语言，现有或开源框架、平台、模块、基础库的重用策略；
• 系统结构：包括系统的网络部署结构，子系统划分，推荐用 UML 部署图、包图描述；
• 关键技术设计：每一个系统关键点不同，但通常都会有安全设计，一些算法的设计；
• 接口设计：包括协议栈，子系统间的接口数据结构，子系统间的业务流程描述。业务流程推荐用 UML 序列图描述；
• 数据设计：流动的数据已经过接口设计，这里描述要存储的数据，数据的组织形式不同，好比 NoSQL，NewSQL，SQL 等不一样类型，描述方式也会不同，关系数据库推荐用 ER 模型描述顶层逻辑结构，字段表描述物理结构；
• 质量预测：对遗留缺陷率、平均无端障运行时间等质量指标进行预测，提出可能出现的缺陷和问题。

5）架构总结

• 自底向上：由点及面，步步为营，经过用例堆积，分类，概括，划分，内聚，逐步扩大范围，再经过剥离，复用，从业务架构到技术架构；

• 自顶向下：洞察客户背后的本质需求，定义问题，分析问题，问题分类，优先级，升层思考，一上来自带上帝视角。

实际应用，二者结合。

5. 设计规范

创建用例后，因为对用例分析的方法差别可能生成不一样的领域模型。

1）模型约束

推导出模型过程当中，须要参考业界沉淀出来的经验，好比 sold 原则，开闭原则等：

• GRASP 设计原则（职责分配原则）
• 信息专家原则(information)
• 创造者原则(creator)
• 低耦合原则(low coupling)
• 高内聚原则(high cohesion)
• 控制器原则(controller)
• 多态原则(polymorphism)
• 纯虚构(pure Fabrication)
• 中介原则(indirect)
• 受保护变量原则(protected Variations)

2）设计原则

GRASP 原则，设计原则有不少，咱们进行架构设计的主导原则是 OCP（开闭原则），在类和代码的层级上有：SRP（单一职责原则）、LSP（里氏替换原则）、ISP（接口隔离原则）、DIP（依赖反转原则）；在组件的层级上有：REP（复用、发布等同原则）、CCP（共同闭包原则）、CRP（共同复用原则），处理组件依赖问题的三原则：无依赖环原则、稳定依赖原则、稳定抽象原则。这些原则是前人大量的经验总结，好比设计模式的原则，SOLID 是几个重要编码原则的缩写：

• 开闭原则（Open Close Principle）：开闭原则就是说对扩展开放，对修改关闭，在程序须要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果；

• 里氏代换原则（Liskov Substitution Principle）：里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一；

• 依赖倒转原则（Dependence Inversion Principle）：这个是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体；

• 接口隔离原则（Interface Segregation Principle）：这个原则的意思是：使用多个隔离的接口，比使用单个接口要好，仍是一个下降类之间的耦合度的意思，从这儿咱们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。因此上文中屡次出现：下降依赖，下降耦合；

• 迪米特法则（最少知道原则）（Demeter Principle）：为何叫最少知道原则，就是说：一个实体应当尽可能少的与其余实体之间发生相互做用，使得系统功能模块相对独立；

• 合成复用原则（Composite Reuse Principle）：该原则是尽可能使用合成/聚合的方式，而不是使用继承。

3）设计模式

在编码过程当中，前人抽象出来的 23 个设计模式也是很值得参考的：

【建立型模式】

• 简单工厂模式（Simple Factory）
• 工厂方法模式（Factory Method）
• 抽象工厂模式（Abstract Factory）
• 建立者模式（Builder）
• 原型模式（Prototype）
• 单例模式（Singleton）

【结构型模式】

• 外观模式（Facade）
• 适配器模式（Adapter）
• 代理模式（Proxy）
• 装饰模式（Decorator）
• 桥模式（Bridge）
• 组合模式（Composite）
• 享元模式（Flyweight）

【行为型模式】

• 模板方法模式（Template Method）
• 观察者模式（Observer）
• 状态模式（State）
• 策略模式（Strategy）
• 职责链模式（Chain of Responsibility）
• 命令模式（Command）
• 访问者模式（Visitor）
• 调停者模式（Mediator）
• 备忘录模式（Memento）
• 迭代器模式（Iterator）
• 解释器模式（Interpreter）

架构落地

说了这么多，架构如何落地？相信这个是你们最关心的，前文咱们已经从总体上创建了系统设计的方法论，再从 it 领域上升到通用商务领域的设计思惟，在系统设计的层面又步步为营给出了工具和剖析模型创建架构推导的一步流程。

其实到了这一步，架构设计已经到了柳暗花明的阶段了，由于咱们已经已经把最核心的环节都弄通了，接下来无非对症下药，根据需求找到系统薄弱的地方，相应地使用适用的工具来发挥最大的做用。

1. 行业架构

目前大部分行业其实都已经有相对稳定成熟的应用架构，也造成了基本的套路，好比金融行业有传统的基于 IOE 的商业应用架构，也有新型互联网的去 IOE 基础上的架构，好比微服务化的流行，在即时通讯的消息架构也是有成熟的解决方案。另外产业互联网各个传统行业的互联网化也能够应用边缘计算架构来实现。

2. 技术架构

行业下沉到技术架构层面，从微小企业到大型企业应用的解决方案，都逃不过网关设计，流量管理，服务治理，容错设计，监控告警，性能调优，数据管理等环节，而这方面的设计实现，业界也提供了成熟的开源解决方案，能够参考《分布式设计知识体系》一文，除了巨型企业须要自研外，多数开源的工具已经能够知足大部分需求，架构设计其实就是选择最适当的工具来解决咱们的问题。

总结

系统设计犹如医生看病须要对症下药，医生须要博学多才精通药理，才能对症下药，就像架构师经验丰富，懂得各类软件工具（药）的利弊，各类设计原则和设计理论（药理）能够设计出架构图（药方），把软件工具精妙的组合在一块儿。

学习的最佳方式是先进行比喻，其次是模仿，最后回归到概念的本质定义。一个好的软件架构师，一样可能成为很好的 hr 专家。本文共分为三个部分从思惟讲起到系统逆向分析，到后面的正向设计。从“道，理，术”三个角度诠释了系统架构设计的全面知识体系。

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”