关于架构设计:架构设计的本质

简介： 实际上架构只是零碎设计外面的一个重要环节，除了架构还蕴含了商业诉求，业务建模，系统分析，零碎设计等重要畛域。本文尝试从更高视角从新扫视架构设计的工作，把架构设计的回升到零碎设计的平面空间去摸索，最终勾画出零碎设计的全域常识体系。

作者 | 编程原理林振华

【问题】

• 什么是零碎设计，零碎设计的外围是什么？
• 如何训练零碎设计的思维模式？
• 有什么办法来帮忙咱们了解简单的零碎？
• 如何进行系统分析？
• 架构设计的实质是什么？
• 如何进行架构设计？
• 如何进行业务领域建模？
• 模型如何推导出架构设计？
• 架构设计须要遵循哪些标准？

【关键词】

零碎思维，系统分析，零碎设计，架构元素，架构视图，架构模型，业务模型，概念模型，零碎模型，分析模型，设计模型，用例驱动，畛域驱动，物件，性能，物件构造，性能交互，利益，架构工具，决策抉择，架构师，架构图

全文概要

软件从业人员的成长路线大体是在治理线和技术线上造成冲破，当然也有联合起来井水不犯河水的。而技术上的谋求，架构师则是一个重要的门槛，对于刚入行的程序员可能会认为架构师就是画架构图的，诚然架构师很重要的一个职责是绘制架构图，但这只是其中一个很小的环节而已。

实际上架构也只是零碎设计外面的一个重要环节，除了架构还蕴含了商业诉求，业务建模，系统分析，零碎设计等重要畛域。本文尝试从更高视角从新扫视架构设计的工作，把架构设计的回升到零碎设计的平面空间去摸索，最终勾画出零碎设计的全域常识体系。

思维剖析

1. 零碎总览

人类社会活动中的不论大大小小的，简略抑或简单的事物，总要先呈现在咱们的脑海里，而后再投射到事实的物理空间来。咱们总是在手不释卷地谋求美妙的事物，但现实存在的问题就是，首先咱们的脑袋也了解不了太过简单的货色，其次脑海里的设想有时候也很难实在无损的映射成事实的零碎，再者因为总是资源无限的，咱们并没有花不完的估算。

归纳起来设计一个零碎，或者奢侈的说，做一件事件，咱们须要解决以下问题：

在解决以上提出的问题前，首先申明咱们要实现的是一个零碎，而不是随便混搭的一件物品，毕竟当初探讨的不是行为艺术。那么就须要先来理解零碎的定义:

零碎是由一组实体和实体之间关系形成的汇合，其性能大于各个实体性能之和。

零碎能够分为天然零碎和人工零碎，然而本文特指须要人类参加的人工零碎。

天然零碎：

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

人工零碎：

• 机械系统
• 电子系统
• 操作系统
• 社会零碎

1. 零碎演变

下面谈到在零碎设计流程次要是应用了剖析思维和零碎思维的联合，当然人类思维还有其余的运作模式，比方批评思维，翻新思维和发散思维等，以此衍生的又是另外一套截然不同的方法论。上面咱们次要剖析零碎设计过程中的思维流动。

通常谈起架构师就会联想到各式各样的架构图，谈架构图就要搞清楚什么是架构设计，那么架构设计之前是什么呢？架构设计是整个零碎建设的外围环节，犹如设计图纸之于修建那么重要，那架构设计之上应该就是零碎设计了。先搞清楚零碎设计的定义：

零碎设计是依据系统分析的后果，使用零碎迷信的思维和办法，设计出能最大限度满足所要求的指标零碎的过程。

1）业务形容

上节弄清楚零碎的概念，也就是先把边界框定下来，那么咱们要实现的无非就是以上类别的零碎。天然零碎是人造造成的，或者你违心的话也能够认为是盘古开天辟地造成的，那也能够归为人为零碎。我这么说的起因是尝试把视角从软件这个畛域往更加宏观的方向晋升，让咱们临时忘掉软件架构师这一积重难返的角色。

假如当初咱们想登上火星，言下之意是须要借助一套设施要把人类送到火星上，大胆一点，施展仅存那点为数不多的物理常识储备，要设计出一套零碎，可能把人类送到火星。这个时候老板就是违心出资去火星奢华 7 日游的金主，那么须要一个负责人来实现这趟旅程，咱们权且把这个负责人就称为登火旅行零碎架构师（叫总设计师也行，不须要在意这种细节）。那么这个零碎架构师的工作，就是把登陆火星的一系列需要和指标转化成为足于撑持登陆火星宏大工程的零碎架构。

依据零碎总览提到的问题，先一一作答。

因为人命关天，这项工作看起来是挺简单的，首次接到这个单子时我心田是徘徊的。然而答复了以上问题后，感觉清朗了不少，咱们在实现零碎性质，受众，利益和指标的剖析和解答后，能力进入到零碎的架构阶段。

首先对以上提到的需要，咱们先用动画片外面的简略画面为根底来描述咱们的设计，而后大抵依据能想到的过程实现首次业务流程的形容。

业务流程画图元素：火箭，机舱，地球，火星，来回，根底性能（平安，舒服，老本）

通过以上的形容，根本涵盖了火星旅程的四个阶段：登机，航行，下机玩耍，返程，这实质上跟咱们平时搭个飞的去趟浪漫的土耳其也是差不多的。而在此之前咱们脑海里可能还是一片混沌，沉溺在登陆火星这项浩瀚的工程而不晓得从而动手。

从混沌到开始有点脉络，其实无形中曾经实现了一次建模，咱们称为业务建模。翻回去查阅零碎总览的表格，其实咱们曾经把需要这个维度大抵列举进去了，把登陆火星的几大畛域给拆散开来了。那么接下来就是要把登陆火星这个我的项目的主线给阐明分明。

2）概念形象

怎么把这件事的主线阐明分明？滔滔不绝的把一件事件讲完其实反而是很难讲明确，除非这件事件自身足够非常简单的。那么就须要抓重点的来说，这个时候就须要一个叫做“概念”的工具。

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

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

这里交叉讲一下概念的利用，比“傅立叶级数”这个概念，我敢打赌有 80% 的人不晓得所谓何物，然而没关系，咱们并不是要来科普这个概念，先依据百度百科来看看这个概念的形容：

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

说回来，这里的语境就是在大家都独特了解承受这些根底概念后，通过一系列简单组合的高级概念，也仍然可能清晰谨严的表达出来，上面傅里叶级数的产生过程的动图看看就好。

好了，当初咱们晓得了概念这个工具的重要性和性能，后面咱们曾经列举了登陆火星要做的事件，那么当初就须要准确简洁的把这件事给说分明了，这个是个艰难的工作，因为如果主线没有梳理清晰，前面整个工程将万劫不复。

在业务建模后就是概念建模，作为架构设计的输出，这个阶段就须要对外围业务的充沛了解，同时在基础性和通用性方面的性能也须要同时思考，这个阶段须要大量的业务专家和各个领域的科学家通力协作，保障对系统的了解没有偏差。通过一系列的概念形象和组合，最终输入登陆火星工程的架构图，这里只是用于阐明登陆火星我的项目同样遵循这业务 - 概念 - 架构 - 设计的流程，不要在意架构图自身合不合理。

3）零碎落地

当然这还远远不够，零碎之所以简单，就是咱们对系统总有有数更多的要求，更多的性能，更好的性能，那么接下来就是对各个模块进行剖析，细化，设计和施行。当然咱们不会班门弄斧真的在这里去剖析登陆火星的理论流程，以上这个例子尽管比拟粗旷，然而根本也描述了一个简单零碎建设的过程，也就是从需要，建模到架构的思维过程，是从最原始的登火需要一步步扩大的过程。

其实咱们还能够举个小一点的案例，比方一个乏味的需要“赚钱”，引申进去就是做一个能盈利商业我的项目架构，有趣味的同学能够依据这个思维模式一步一步勾画出整个流程进去，置信这也是一个不错的办法，兴许还真能解决些许困惑。上面演示的就是登月过程宏观层面落地的步骤。

1. 架构思维

1）架构指标

始终以来我听过很多人在讲架构，有些人在做架构，然而很难探讨出一个大家都称心的定义，什么是架构师，架构师须要做哪些工作？或者说很少有往深的去思考，只晓得被称为架构师阐明这个人很厉害。在我毕业的时候有个同学打趣的跟我说，你们做程序的无非就是增删改查，过后我竟无言以对，过后脑海里浮现的是一系列工具的利用技巧，比方 tomcat，nginx 的应用，还有对业务的翻译。

随着对业务的贴近和对计算机技术的进一步意识，我从新扫视“这世上的零碎无非就是增删改查”，这句话说对也对也不对，这句话就跟计算机软件无非就是 0 和 1 的汇合，也对也不对。特地是对刚入行的人可能感觉设计离本人比拟远，因为习惯了关上 idea 才开始思考业务，写代码才开始思考畛域模型，这是十分不好的习惯，如同如果没有在 coding 状态下是无奈进行建模思考，这个很难，须要长久的训练能力达成设计阶段进行思考。

架构设计只是零碎设计外面的一个阶段，而零碎设计是利用建设外面的外围环节，有一些简略的利用建设是不须要零碎设计的，当然有一些简单的利用，在能力超强的工程师团队，有足够的默契后，也能够间接进行建设。

软件架构之道最外围的问题是解决复杂性的问题，并且在解决问题的过程中找到最佳的平衡点，既要简略又能满足倒退。形容零碎设计的实质，就是实现纵向上的工夫，横向上的空间进行思考，布局出决策门路，最终拿到指标后果。

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

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

2）架构过程

天然在增熵，而零碎架构过程其实就是减熵的过程，一个架构的诞生始于指标的确立，而后是对需要的刻画，继而是落地办法的抉择。

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

• 确定零碎实体对象和预期性能
• 形象零碎实体之间的关系，性能与实体的关系
• 划定零碎的边界和外部环境的关系
• 预测零碎带来的成果

在架构过程中，很重要的一项工作就是识别系统的实体关系和性能关系，进而对系统成果进行预测，也就是在实现一系列的剖析建模工作后推导进去的零碎架构须要在预测上达到咱们要的成果，那么零碎预测通常有如下四种形式：

• 教训
• 试验
• 建模
• 推理

3）零碎思维

零碎思维不等于系统化思考，与零碎思维并列的能够是批评思维，剖析思维，翻新思维，而咱们谋求的是元认知，也即是意识到本人处于何种思维模式。零碎思维指标：

• 了解零碎是什么
• 预测零碎的走向
• 为决策提供常识反对

零碎思维首先是高效地了解剖析现存的零碎，对系统重构做好理论指导根底。

这一节介绍了设计一个零碎须要经验哪些重要的环节，并且强调了谋求利益是零碎设计的外围诉求。而后通过登陆火星这项工作把一个宏大的工程变成了可了解的独立步骤，并且还有模有样的画出了架构图，体现了对业务建模到架构输入的流程。上面章节咱们将会开展来介绍一套外围的方法论，如何破局零碎架构设计。

系统分析

上一节议论了零碎设计的心智模型和投射到物理世界的演变法则，但前提是建设在曾经具备丰盛零碎设计教训根底上。而在进行零碎架构之前，须要先对系统分析有肯定的了解，好比咱们制作发动机之前，得先把发动机拆下来好好钻研一番，间接上来就要设计出发动机有点像海市蜃楼。

本节将提供一套根底的办法，来对现有零碎进行剖析，得出一些零碎架构相干的推论。依照常规须要先搞清楚系统分析的概念：

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

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

构造是指在一个零碎或者资料之中，相互关联的元素的排列、组织关系。

而零碎在物质世界外面当然也遵循这样的规定，剖析零碎跟剖析银河系也一样，须要对它的组成元素和元素之间的关系进行剖析。而对系统的合成也是考究办法的，能够参考以下总结的一些方向：

• 体系演绎
• 层级合成
• 逻辑关系
• 自顶向下
• 自底向上
• 由内向内
• 由内而外

1. 实体剖析

实体指零碎物理时空存在的单元，彼此通过肯定的构造造成零碎，那么在剖析实体之前，咱们能够带着上面的问题进行剖析：

• 零碎是什么？
• 形成零碎的元素有哪些？
• 零碎元素之间的构造是什么？
• 零碎的边界在哪里？
• 零碎的应用场景是什么？

实体是零碎的一项根底属性，是零碎的物理体现或信息体现。对性能的执行起工具性作用，而形容实体通常能够应用以下工具来表白：

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

实体之间的关系就是构造，剖析构造时须要对实体进行合成，实体能够建模为对象及其之间的构造，进一步能够合成为小的实体，又能够聚合起来称为零碎自身，对实体之间的各种构造剖析则能够得出零碎架构，即是把性能元素组合成物理块时所用的编排形式。

1）剖析实体

• 对实体的载体进行形象聚类，造成对象，体现出边界
• 用适当的档次来合成架构的实体

2）剖析关系

即是实体的构造，是对象之间存在稳固关系，有助于性能交互的执行零碎实体有如下关系：

• 空间拓扑关系
• 连贯性关系
• 地址关系
• 程序关系
• 成员关系
• 所有权关系
• 人际关系

1. 功能分析

下面一节咱们理解了零碎的物理根底，对组成零碎的实体进行合成，剖析，进而对实体的关系形容为构造，构造形象是得出架构的根底步骤，而零碎物理根底存在的理由是为了实现咱们的诉求，也即是零碎的性能。毕竟万物皆有因，存在即正当，零碎构建最终也是要达成咱们的志愿，实现这个诉求才算是合格的架构。剖析模式相对来说毕竟简略，毕竟实体是无形的便于了解，而性能则是由实体组合涌现进去的属性，功能分析过程须要跟实体一直的交互交叉。

对于零碎性能其实能够奢侈的认为就是动宾短语的汇合，性能 = 动词 + 宾语，含意就是实体状态变动的过程，就是性能的体现，具体分析下文会具体开展。性能 = 主体 + 操作 + 操作对象，比方嘴巴有“吃饭”性能，飞机有“搭载乘客”性能，报表平台有“展现报表”性能。

• 操作：对象经验的一种转换模式，过程设计操作数的状态变动；
• 操作对象：操作数是一个对象，在某段时间内稳固且无条件存在，操作数不须要先于性能的执行而存在，操作数可能会由性能中的过程局部来创立，批改或耗费。

总结起来，系统分析就是建设一套方法论，去剖析简单的零碎，令零碎不再那么难懂。

零碎设计

通过了上几节的思维训练和零碎逆向剖析，咱们也大略了解了零碎设计的流程和零碎架构的造成过程，本节将介绍零碎设计，包含设计工具，需要剖析，模型建设，架构推导，设计规范残缺的零碎设计流程。

零碎设计，即设计出一套良好的零碎架构，就是构建一套具备必要复杂度又不难懂的零碎。上面在介绍方法论的同时，同时会交叉一个数据平台的大抵设计过程。

在进入本章节零碎设计前，咱们先要来学习学习一个架构 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

1. 需要剖析

本节不打算讲需要分析师的工作流程，因为咱们曾经很相熟需要分析师对需要的剖析过程了，所以无需多言，在讲需要之前咱们先来看看架构师须要实现的工作。

架构师并不是全能的通才，无奈理解所有粗疏的需要，所以架构师要做的就是简化零碎的复杂度，打消业务歧义，致力于输入强壮兼容的零碎架构。因为零碎需要剖析须要由架构师这个角色全程参加，深度了解业务，上面咱们简略对架构师角色进行探讨。

1）架构角色

咱们先看看传统零碎设计两大外围角色的定义：

零碎架构师：是在信息系统研发中，负责根据需要来确定次要的技术抉择、设计零碎的主体框架结构，并负责搭建施行的人。

零碎分析师：是在信息系统研发中，负责通过需要剖析确认零碎的需要，并进而造成零碎产品设计的人。通常他们也会波及可行性评估、项目管理、开发前评估、需要验证等工作。

传统意义的零碎开发分为零碎架构师和零碎分析师两个角色，然而随着互联网的疾速倒退，现在零碎建设越来越趋向于将两个角色联合起来，那么互联网时代架构师有如下职责：

• 理解问题畛域，打消歧义
• 建立业务指标，形象业务用例
• 实现涉众剖析，发现零碎次要受益者
• 划清零碎边界，确立对外交互方式
• 划分优先级别，聚焦系统核心诉求
• 剖析业务需要，输入业务模型
• 形象业务概念，输入概念模型
• 推导零碎架构，输入架构模型
• 负责技术选型，实现零碎落地

架构师是软件开发流动中的泛滥角色之一，它可能是一个人、一个小组，也可能是一个团队，咱们剖析的是架构师这个角色，能胜任这个角色的才是架构师，那么在这个角色上能做得更加杰出的就是好的架构师。

以上架构师职责是整体上的形容，在细分畛域有不同的分类。微软对架构师有一个分类参考，咱们参考一下，他们把架构师分为 4 种：

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

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

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

2）利益剖析

首先当然是要确立好客户，所谓客户第一，听起来很简略，如果只是繁多的服务好客户，那的确不算很难。难的是如果同时存在多个业务方向的客户，而且客户间接的利益产生交加，而且存在矛盾，怎么衡量好利益调配，辨别客户利益优先级，才是艰难的。

不忘初心这一点尤为难得，很多我的项目做着做着就偏离了当初的指标，这个过程咱们肯定要紧紧抓住零碎最重要的受益者，梳理好零碎泛滥涉众的利益调配。

3）资源评估

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

4）需要标准

用户的诉求体现为需要的输入过程，不同档次合成需要得出了不同的复杂度，咱们晓得架构师的一项重要职责就是打消歧义，精准的把握需要来匹配用户的诉求。那么就须要一系列标准来保障需要采集的过程中不失真。

上面列出了需要采集过程的一些领导准则：

• 每个软件需要是否都有惟一的标识符？
• 每个软件需要都能够验证吗？（如果可能，是否可正规化，量化）
• 是否对每个软件要求进行了优先排序？
• 所有不稳固的软件要求是否都已表明？
• 软件需要是否残缺？（涵盖了所有用户要求，思考了所有相干的输出状况）
• 软件要求是否统一？
• 是否明确指出了软件需要之间的重叠穿插？
• 是否明确规定了初始零碎状态？
• 软件需要是否表白了逻辑模型，而不是实现模式？
• 软件需要是否以结构化的形式示意为抽象层次？
• 是否足够分明，逻辑模型的构造
• 软件要求是否已正式形式化？
• 是否已证实软件需要的要害属性？
• 所有形式化的图表资料是否都随附了短缺解释性文字？
• 是否针对我的项目团队缺乏经验的畛域形容了探索性原型？

5）需要形容

在进行需要形容时，咱们能够从多个角度来扫视需要是否正当地表达出来：

• 满足需要，能带来什么价值，合乎什么利益诉求？
• 需要无奈满足时，会带来什么危害，有何潜在危险？
• 需要是否紧迫，必须在什么时间段内实现？
• 多个需要间接是否产生耦合，实现一个需要后是否带来了新的问题？
• 是否能多个备选计划来实现需要？

6）需要采集

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

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

需要背地：

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

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

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

1. 模型建设

在零碎设计这个阶段，咱们曾经介绍了如何使用工具，还有用户需要的治理，接下来就是要把需要“消化”成咱们须要的架构。然而架构不是平白无故就产生的，前文咱们用登陆火星的案例也大略形容了零碎的建设过程，那么在推导出架构之前，把用户不那么清晰的诉求转化成谨严的业务概念模型就很有必要了。

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 中最常见的一类设施是对象长久化的具体实现。

【建模过程】

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

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

• 畛域常识：首先咱们剖析我的项目在畛域分层后的概念我的项目波及到：

  • 名词：分析师，工程师，客户，小二
  • 报表，报表模板，权限，角色，告警，人群，流动，决策
  • 动词：登陆，创立权限，匹配权限，受权，建表，圈人，营销
  • 实体：报表，报表模板，权限，角色，人群，流动，决策
  • 值对象：告警
  • 服务：登陆，创立权限，报表匹配权限，受权给用户，创立报表，圈人，营销
  • 模块：报表域，权限域，洞察域，营销域
  • 聚合根：报表（报表模板，报表数据），权限（权限，角色），流动（人群，营销规定）
  • 工厂：报表模板工厂，人群工厂，决策工厂，权限工厂
  • 资源库：数据库，音讯，内部接口
• 畛域模型：通过对畛域常识的消化，就能够输入畛域模型图。

1. 架构推导

通过了漫长的前戏 – 模型建设，本篇终于到了架构设计了，真的不容易啊。一开始我总是在纠结架构师应该输入什么架构图，什么才是规范的架构图，然而当我了解什么是架构，架构造成的过程后，我不再纠结了，架构存在每一个阶段，以不同的状态呈现，业务，产品，技术，施行不同的阶段都须要一张提纲挈领的架构图来领导零碎建设。

零碎架构这个词常常放在一起说，以至于咱们感觉理所当然，常常一概而论。零碎指的是由一堆实体组成的一个具备某些性能的整体，而架构则是架和构，即是框架和构造，也就是具备稳固诉求而且是能够撑持整体的组件。零碎能够没有架构，比方咱们乱哄哄的零碎。然而零碎同时也是须要架构的，架构就像是零碎的 DNA，架构决定了零碎的走向和生命周期，好的架构能够撑持零碎长久运行和更新迭代。

1）架构定义

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

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

2）架构分类

随着互联网的倒退，利用从单体到分布式，到现在基础设施的改革，咱们迎来了云原生时代，零碎的架构随着根底技术的冲破也一直演变，单体利用最简略最常见的架构就是分层架构，比方咱们相熟的 MVC 架构，因为业务倒退到肯定层度后，须要对服务进行解耦，进而把一个繁多的大零碎按逻辑拆分成不同的子系统，通过服务接口来通信，面向服务的设计模式，最终须要总线集成服务，而且大部分时候还共享数据库，呈现单点故障的时候会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的呈现。

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

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

3）推导架构

先问题，后定位，即：先使命后愿景，解决什么问题？先定义问题，何为问题，有矛盾即存在问题，业余的形象和架构常识，以及背地的演绎和演绎的逻辑思考办法，加上丰盛的业务用例，通过逻辑排列，造成业务架构，首先咱们会用以下的表格来形容问题。

• 演绎

  • 将用例进行形象分类成为业务模型
  • 将业务模型进行 IT 层面的思考，减少非功能性的组件造成零碎模型

• 演绎

  • 将用例以及问题进行分类聚合
  • 业务用例造成零碎架构过程须要进行演绎
  • 对行为稳定性，性能思考的总结，演绎为通用组件

4）架构输入

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

5）架构总结

• 自底向上：由点及面，步步为营，通过用例沉积，分类，演绎，划分，内聚，逐渐扩大范围，再通过剥离，复用，从业务架构到技术架构；
• 自顶向下：洞察客户背地的实质需要，定义问题，剖析问题，问题分类，优先级，升层思考，一上来自带上帝视角。

理论利用，两者联合。

1. 设计规范

建设用例后，因为对用例剖析的办法差别可能生成不同的畛域模型。

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 根底上的架构，比方微服务化的风行，在即时通信的音讯架构也是有成熟的解决方案。另外产业互联网各个传统行业的互联网化也能够利用边缘计算架构来实现。

1. 技术架构

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

总结

零碎设计犹如医生看病须要隔靴搔痒，医生须要博览群书精通药理，能力隔靴搔痒，就像架构师经验丰富，懂得各种软件工具（药）的利弊，各种设计准则和设计实践（药理）能够设计出架构图（药方），把软件工具精妙的组合在一起。

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