这样阐述架构设计的本质，真的相当炸裂……
dbaplus社群约 30 分钟人类社会活动中的不管大大小小的，简单抑或复杂的事物，总要先出现在我们的脑海里，然后再投射到现实的物理空间来。我们总是在孜孜不倦地追求美好的事物，但现实存在的问题就是，首先我们的脑袋也理解不了太过复杂的东西，其次脑海里的想象有时候也很难真实无损的映射成现实的系统，再者由于总是资源有限的，我们并没有花不完的预算。归结起来设计一个系统，或者朴素的说，做一件事情，我们需要解决以下的问题：
在解决以上提出的问题前，首先声明我们要实现的是一个系统，而不是随意混搭的一件物品，毕竟现在讨论的不是行为艺术。那么就需要先来了解系统的定义：
系统是由一组实体和实体之间关系构成的集合，其功能大于各个实体功能之和。
系统可以分为自然系统和人工系统，但是本文特指需要人类参与的人工系统。
自然系统：
人体系统
生态系统
大气系统
水源系统
人工系统：
机械系统
电子系统
操作系统
社会系统
4.2系统演化
上面谈到在系统设计流程主要是使用了分析思维和系统思维的结合，当然人类思维还有其他的运作模式，比如批判思维，创新思维和发散思维等，以此衍生的又是另外一套截然不同的方法论。下面我们主要分析系统设计过程中的思维活动。通常谈起架构师就会联想到各式各样的架构图，谈架构图就要搞清楚什么是架构设计，那么架构设计之前是什么呢？架构设计是整个系统建设的核心环节，犹如设计图纸之于建筑那么重要，那架构设计之上应该就是系统设计了。先搞清楚系统设计的定义：
系统设计是根据系统分析的结果，运用系统科学的思想和方法，设计出能最大限度满足所要求的目标系统的过程。
业务描述
上节弄清楚系统的概念，也就是先把边界框定下来，那么我们要实现的无非就是以上类别的系统。自然系统是天然形成的，或者你愿意的话也可以认为是盘古开天辟地形成的，那也可以归为人为系统。我这么说的原因是尝试把视角从软件这个领域往更加宏观的方向提升，让我们暂时忘掉软件架构师这一根深蒂固的角色。
假设现在我们想登上火星，言下之意是需要借助一套设备要把人类送到火星上，大胆一点，发挥仅存那点为数不多的物理知识储备，要设计出一套系统，能够把人类送到火星。这个时候老板就是愿意出资去火星豪华7日游的金主，那么需要一个负责人来实现这趟旅程，我们姑且把这个负责人就称为登火旅行系统架构师（叫总设计师也行，不需要在意这种细节）。那么这个系统架构师的工作，就是把登陆火星的一系列需求和目标转化成为足于支撑登陆火星庞大工程的系统架构。
根据系统总览提到的问题，先一一作答。
维度 | 问题 | 方案 |
性质 | 这件事是否合法合规？ | 必须确认旅客人身安全 |
受众 | 这件事情最终谁是受益方？ | 主体是金主，参加系统建设的供应商 |
利益 | 这件事做完能带来什么收益？ | 美好的旅行回忆，提升人类航天水平 |
目标 | 要做一件什么样的事情？ | 火星旅行，把人安全送到火星再安全送回来 |
需求 | 怎样把这件事合理的列举出来？ | 人身安全 住的舒服 吃的美味 少花点钱 旅程快点 最好下次能大幅减少成本 全程跟拍 带回纪念品 |
抽象 | 怎样把这件事的主线说明清楚？ | 输出业务架构/概念架构/系统架构 |
设计 | 选择什么工具把这件事实现出来？ | 技术选型组合 |
方向 | 这件事是否违背了我们的初衷 | 不断验证测试 |
由于人命关天，这项工作看起来是挺复杂的，初次接到这个单子时我内心是彷徨的。但是回答了以上问题后，感觉明朗了不少，我们在完成系统性质，受众，利益和目标的分析和解答后，才能进入到系统的架构阶段。首先对以上提到的需求，我们先用动画片里面的简单画面为基础来描绘我们的设计，然后大致根据能想到的过程完成初次业务流程的描述。
业务流程画图元素：火箭，机舱，地球，火星，来回，基础功能（安全，舒适，成本）
通过以上的描述，基本涵盖了火星旅程的四个阶段：登机，航行，下机游玩，返程，这本质上跟我们平时搭个飞的去趟浪漫的土耳其也是差不多的。而在此之前我们脑海里可能还是一片混沌，沉溺在登陆火星这项浩瀚的工程而不知道从而入手。从混沌到开始有点头绪，其实无形中已经完成了一次建模，我们称为业务建模。翻回去查阅系统总览的表格，其实我们已经把需求这个维度大致列举出来了，把登陆火星的几大领域给分离开来了。那么接下来就是要把登陆火星这个项目的主线给说明清楚。
概念抽象
怎样把这件事的主线说明清楚？滔滔不绝的把一件事情讲完其实反而是很难讲明白，除非这件事情本身足够非常简单的。那么就需要抓重点的来说，这个时候就需要一个叫做“概念”的工具。
概念是抽象的、普遍的想法，是充当指明实体、事件或关系的范畴或类的实体。
简单来说，概念就是用简单的一个词汇，就可以让在座的大家都能准确无误的理解这个词汇所表达的含义。这个是语言独特的魅力，可以说有个概念这个武器，才有了人类多次工业革命的文明大爆发。有了“概念”这个工具，再对概念进行组合，会爆发出无穷的生产力。
这里穿插讲一下概念的应用，比“傅立叶级数”这个概念，我敢打赌有80%的人不知道所谓何物，但是没关系，我们并不是要来科普这个概念，先根据百度百科来看看这个概念的描述：
若在整个数轴上:
且等式右边级数一致收敛，则有如下关系式:
一般地说，若 是以 为周期且在上可积的函数 ，则按上式计算出的称为函数(关于三角函数系)的傅里叶系数，以的傅里叶系数为系数的三角级数称为(关于三角函数系)的傅里叶级数，记作：
其中，记号“”表示上式右边是左边函数的傅里叶级数
先不要怕，我这么说的目的不是为了让大家搞懂什么是傅立叶级数，这里我们可以看出即使这么鬼畜概念也是很普通的基础概念元素组成的，比如收敛公式，比如三角函数，比如Σ求和概念，甚至像1，2，3这些阿拉伯数字。这里不得不说学数学最核心的环节就是深刻理解概念，没有之一。说回来，这里的语境就是在大家都共同理解接受这些基础概念后，经过一系列复杂组合的高级概念，也依然能够清晰严谨的表达出来，下面傅里叶级数的产生过程的动图看看就好。
好了，现在我们知道了概念这个工具的重要性和功能，前面我们已经列举了登陆火星要做的事情，那么现在就需要精确简洁的把这件事给说清楚了，这个是个困难的任务，因为如果主线没有梳理清晰，后面整个工程将万劫不复。
在业务建模后就是概念建模，作为架构设计的输入，这个阶段就需要对核心业务的充分理解，同时在基础性和通用性方面的功能也需要同时考虑，这个阶段需要大量的业务专家和各个领域的科学家通力协作，保证对系统的理解没有偏差。经过一系列的概念抽象和组合，最终输出登陆火星工程的架构图，这里只是用于说明登陆火星项目同样遵循这业务-概念-架构-设计的流程，不要在意架构图本身合不合理。
系统落地
当然这还远远不够，系统之所以复杂，就是我们对系统总有无数更多的要求，更多的功能，更好的性能，那么接下来就是对各个模块进行分析，细化，设计和实施。当然我们不会班门弄斧真的在这里去分析登陆火星的实际流程，以上这个例子虽然比较粗旷，但是基本也描绘了一个复杂系统建设的过程，也就是从需求，建模到架构的思维过程，是从最原始的登火需求一步步扩展的过程。其实我们还可以举个小一点的案例，比如一个有趣的需求“赚钱”，引申出来就是做一个能盈利商业项目架构，的有兴趣的同学可以根据这个思维模式一步一步勾画出整个流程出来，相信对这是也不错的方法，也许还真能解决些许困惑。下面演示的就是登月过程宏观层面落地的步骤。
4.3架构思维
架构目标
一直以来我听过很多人在讲架构，有些人在做架构，但是很难讨论出一个大家都满意的定义，什么是架构师，架构师需要做哪些工作？或者说很少有往深的去思考，只知道被称为架构师说明这个人很厉害。在我毕业的时候有个同学打趣的跟我说，你们做程序的无非就是增删改查，当时我竟无言以对，当时脑海里浮现的是一系列工具的应用技巧，比如tomcat，nginx的使用，还有对业务的翻译。随着对业务的贴近和对计算机技术的进一步认识，我重新审视“这世上的系统无非就是增删改查”，这句话说对也对也不对，这句话就跟计算机软件无非就是0和1的集合，也对也不对。特别是对刚入行的人可能觉得设计离自己比较远，因为习惯了打开idea才开始考虑业务，写代码才开始思考领域模型，这是非常不好的习惯，好像如果没有在coding状态下是无法进行建模思考，这个很难，需要持久的训练才能达成设计阶段进行思考。架构设计只是系统设计里面的一个阶段，而系统设计是应用建设里面的核心环节，有一些简单的应用建设是不需要系统设计的，当然有一些复杂的应用，在能力超强的工程师团队，有足够的默契后，也可以直接进行建设。
软件架构之道最核心的问题是解决复杂性的问题，并且在解决问题的过程中找到最佳的平衡点，既要简单又能满足发展。描述系统设计的本质，就是实现纵向上的时间，横向上的空间进行考虑，规划出决策路径，最终拿到目标结果。架构师眼里第一件事不是多流行的技术，多高性能的框架，或者多完善的业务模型，而应该聚焦在利益之上。对，这个可能会颠覆一些认知，当我们真正把利益放在首位后，再去考虑接下来要完成的事情，我们的工作才能称得上架构。也就是说，架构师的天职就是最大限度的实现客户的利益，这里的客户可以是市场客户，也可以是协作团队，还可以是同一个团队的项目成员。再直白的说，架构师就是负责把老板画的饼给实现了，在相当长的一段时间内保证产物有足够的利益回报。有人会说那我们做的就是公益项目，就不考虑利益，那我我补充一下，这里说的利益不止是经济收益，还有系统带来的社会价值。那么又有人会说，架构是追求利益回报，那老板的目标就是炒股发大财，请架构师你给我选几支股票吧，那我会说其实优秀的基金经理也可以称为广义上的架构师。
架构过程
自然在增熵，而系统架构过程其实就是减熵的过程，一个架构的诞生始于目标的确立，然后对需求的刻画，继而是落地方法的抉择。所谓条条大路通罗马，有的是一路平川而有的则是崎岖不平，那么架构过程就是不断归类合并同类项，力求最合适的决策选择来实现我们所要达成的愿望。在面对复杂业务的场景下，我们需要做出如下的思考：
确定系统实体对象和预期功能
抽象系统实体之间的关系，功能与实体的关系
划定系统的边界和外部环境的关系
预测系统带来的效果
在架构过程很重要的一项任务就是识别系统的实体关系和功能关系，进而对系统效果进行预测，也就是在完一系列的分析建模工作后推导出来的系统架构需要在预测上达到我们要的效果，那么系统预测通常有如下四种方式：
经验
实验
建模
推理
系统思维
系统思维不等于系统化思考，与系统思维并列的可以是批判思维，分析思维，创新思维，而我们追求的是元认知，也即是认识到自己处于何种思维模式。系统思维目标：
理解系统是什么
预测系统的走向
为决策提供知识支持
系统思维首先是高效的理解分析现存的系统，对系统重构做好理论指导基础。
这一节介绍了设计一个系统需要经历哪些重要的环节，并且强调了谋求利益是系统设计的核心诉求。然后通过登陆火星这项任务把一个庞大的工程变成了可理解的独立步骤，并且还有模有样的画出了架构图，体现了对业务建模到架构输出的流程。下面章节我们将会展开来介绍一套核心的方法论，如何破局系统架构设计。
业务架构：突出了架构治理、架构流程、架构组织结构、架构信息需求以及架构产品等方面 数据架构：定义了组织中架构连续体和架构资源库的结构 应用架构：描述了用于支持此可持续架构实践的功能和服务 技术架构：描述了架构实践中用于支持各架构应用和企业连续体的基础设施需求和部署方式
描述了一种用于根据一组构建块来定义信息系统的方法 展示构建块如何组合在一起 包含一组工具 提供共同的词汇集合 包括推荐标准列表 包括可用于实现构建块的兼容产品列表
参与者 用例 边界 业务实体 包 分析类 设计类 关系 组件 节点
用例图 类图 包图
活动图 状态图 时序图 协作图 泳道图
业务用例模型 概念用例模型 系统用例模型 业务领域模型 系统分析模型 系统设计模型 系统组件模型
业务建模 系统建模 模型分析 模型实施
draw.io StarUML Visual Paradigm
了解问题领域，消除歧义 树立业务目标，抽象业务用例 完成涉众分析，发现系统主要受益者 划清系统边界，确立对外交互方式 划分优先级别，聚焦系统核心诉求 分析业务需求，输出业务模型 抽象业务概念，输出概念模型 推导系统架构，输出架构模型 负责技术选型，完成系统落地
企业架构师EA(Enterprise Architect) 基础结构架构师IA(Infrastructure Architect) 特定技术架构TSA(Technology-Specific Architect) 解决方案架构师SA (Solution Architect)
现有资源评估盘点及资源编排能力 消除歧义分清问题主次能力 业务简化描述，用例抽象思维 通用市场法务市场领域基础常识 业务分析架构推导能力 计算机基础理论知识体系 通用技术栈原理认知 工具使用熟练，排查定位问题能力 技术深度广度 分布式高并发性能调优技能 产品思维
每个软件需求是否都有唯一的标识符？ 每个软件需求都可以验证吗？（如果可能，是否可正规化，量化） 是否对每个软件要求进行了优先排序？ 所有不稳定的软件要求是否都已标明？ 软件需求是否完整？（涵盖了所有用户要求，考虑了所有相关的输入情况） 软件要求是否一致？ 是否明确指出了软件需求之间的重叠交叉？ 是否明确规定了初始系统状态？ 软件需求是否表达了逻辑模型， 而不是实现形式？ 软件需求是否以结构化的方式表示为抽象层次？ 是否足够清楚，逻辑模型的结构 软件要求是否已正式形式化？ 是否已证明软件需求的关键属性？ 所有形式化的图表材料是否都随附了充足解释性文字？ 是否针对项目团队缺乏经验的领域描述了探索性原型？
满足需求，能带来什么价值，符合什么利益诉求 需求无法满足时，会带来什么危害，有何潜在风险 需求是否紧迫，必须在什么时间段内完成 多个需求直接是否产生耦合，完成一个需求后是否带来了新的问题 是否能多个备选方案来完成需求
打破单个游戏壁垒，实现多个游戏数据互通，多游戏，多版本数据融合 底层数据生命周期管理，游戏多服阶段管理 提升经分一键化能力
单游戏壁垒是个困局，本质上是功能缺陷，打通数据壁垒 游戏各个阶段目前是物理删除数据，要多数据底层进行管理 现在是配置报表case by case完成的，需要对由相同特性的报表实现一键生成
可以一次性看更多的数据 可以方便的切换数据 可以更快的看到数据
深入分析用户需求 搞清楚我们的客户是谁？ 定义好问题，搞清楚问题的本质，分析问题矛盾之处，我们要解决什么问题？ 我们要在多大范围内去解决问题，要解决跨度多长时间可预计的问题？ 我们的边界在哪里？ 我们的使命是什么？有了使命后再谈我们自己，愿景是什么？
业务模型 概念模型 系统模型 分析模型 设计模型 物理模型
领域驱动（DDD） 用例驱动（UDD） 四色建模 CRC建模 CQRS建模
参与者：某些具有行为的事物，可以是人，计算机系统或组织 场景：参与者和系统之间的一系列特定的活动和交互 用例：一组相关的成功和失败的场景集合，用来描述参与者如何使用系统来实现目标
用例模型
业务模型
主语：分析师 状语：客户 谓语：制作 定语：某一项业务 宾语：报表
概念模型
系统模型
接口层：该层包含与其他系统进行交互的接口与通信设施，在多数应用里，该层可能提供包括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中最常见的一类设施是对象持久化的具体实现。
用户访谈
领域知识
领域模型
分层架构：MCV，六边形架构，洋葱架构 事件驱动架构 微核架构 微服务架构 云原生架构
演绎
归纳
方案概述：对设计方案的概括性描述 设计约束：包括要遵循的标准或规范，技术上依赖的假设条件等 技术选型：包括系统运行的软硬件环境，研发、测试的软硬件环境，编程语言，现有或开源框架、平台、模块、基础库的重用策略 系统结构：包括系统的网络部署结构，子系统划分。推荐用UML部署图、包图描述 关键技术设计：每个系统关键点不一样，但一般都会有安全设计，一些算法的设计 接口设计：包括协议栈，子系统间的接口数据结构，子系统间的业务流程描述。业务流程推荐用UML序列图描述。 数据设计：流动的数据已通过接口设计，这里描述要存储的数据。数据的组织形式不一样，比如NoSQL，NewSQL，SQL等不同类型，描述方式也会不一样。关系数据库推荐用ER模型描述顶层逻辑结构，字段表描述物理结构。 质量预测：对遗留缺陷率、平均无故障运行时间等质量指标进行预测，提出可能出现的缺陷和问题。
自底向上：由点及面，步步为营，通过用例堆积，分类，归纳，划分，内聚，逐步扩大范围，再通过剥离，复用，从业务架构到技术架构。
自顶向下：洞察客户背后的本质需求，定义问题，分析问题，问题分类，优先级，升层思考，一上来自带上帝视角。
开闭原则（Open Close Principle）开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。 里氏代换原则（Liskov Substitution Principle）里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 依赖倒转原则（Dependence Inversion Principle）这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。 接口隔离原则（Interface Segregation Principle）这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。 迪米特法则（最少知道原则）（Demeter Principle）为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。 合成复用原则（Composite Reuse Principle）原则是尽量使用合成/聚合的方式，而不是使用继承。
简单工厂模式（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）