架构设计的本质(文末送书)
Posted 云时代架构
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了架构设计的本质(文末送书)相关的知识,希望对你有一定的参考价值。
精品技术文章准时送上!
1.问题
1、什么是系统设计,系统设计的核心是什么?
2、如何训练系统设计的思维模式?
3、有什么方法来帮助我们理解复杂的系统?
4、如何进行系统分析?
5、架构设计的本质是什么?
6、如何进行架构设计?
7、如何进行业务领域建模?
8、模型如何推导出架构设计?
9、架构设计需要遵循哪些规范?
2.关键词
系统思维,系统分析,系统设计,架构元素,架构视图,架构模型,业务模型,概念模型,系统模型,分析模型,设计模型,用例驱动,领域驱动,物件,功能,物件结构,功能交互,利益,架构工具,决策选择,架构师,架构图
3.全文概要
软件从业人员的成长路线大体是在管理线和技术线上形成突破,当然也有结合起来相得益彰的。而技术上的追求,架构师则是一个重要的门槛,对于刚入行的程序员可能会认为架构师就是画架构图的,诚然架构师很重要的一个职责是绘制架构图,但这只是其中一个很小的环节而已。而实际上架构也只是系统设计里面的一个重要环节,除了架构还包含了商业诉求,业务建模,系统分析,系统设计等重要领域。本文尝试从更高视角重新审视架构设计的工作,把架构设计的上升到系统设计的立体空间去探索,最终勾勒出系统设计的全域知识体系。
4.思维分析
4.1系统总览
人类社会活动中的不管大大小小的,简单抑或复杂的事物,总要先出现在我们的脑海里,然后再投射到现实的物理空间来。我们总是在孜孜不倦地追求美好的事物,但现实存在的问题就是,首先我们的脑袋也理解不了太过复杂的东西,其次脑海里的想象有时候也很难真实无损的映射成现实的系统,再者由于总是资源有限的,我们并没有花不完的预算。归结起来设计一个系统,或者朴素的说,做一件事情,我们需要解决以下的问题:
维度 |
问题 |
定义 |
性质 |
这件事是否合法合规? |
系统风险 |
受众 |
这件事情最终谁是受益方? |
系统主体 |
利益 |
这件事做完能带来什么收益? |
系统价值 |
目标 |
要做一件什么样的事情? |
系统定位 |
需求 |
怎样把这件事合理的列举出来? |
系统建模 |
抽象 |
怎样把这件事的主线说明清楚? |
系统架构 |
设计 |
选择什么工具把这件事实现出来? |
系统建设 |
方向 |
这件事是否违背了我们的初衷 |
系统验证 |
在解决以上提出的问题前,首先声明我们要实现的是一个系统,而不是随意混搭的一件物品,毕竟现在讨论的不是行为艺术。那么就需要先来了解系统的定义:
系统是由一组实体和实体之间关系构成的集合,其功能大于各个实体功能之和。
系统可以分为自然系统和人工系统,但是本文特指需要人类参与的人工系统。
自然系统:
人体系统
生态系统
大气系统
水源系统
人工系统:
机械系统
电子系统
操作系统
社会系统
4.2系统演化
上面谈到在系统设计流程主要是使用了分析思维和系统思维的结合,当然人类思维还有其他的运作模式,比如批判思维,创新思维和发散思维等,以此衍生的又是另外一套截然不同的方法论。下面我们主要分析系统设计过程中的思维活动。通常谈起架构师就会联想到各式各样的架构图,谈架构图就要搞清楚什么是架构设计,那么架构设计之前是什么呢?架构设计是整个系统建设的核心环节,犹如设计图纸之于建筑那么重要,那架构设计之上应该就是系统设计了。先搞清楚系统设计的定义:
系统设计是根据系统分析的结果,运用系统科学的思想和方法,设计出能最大限度满足所要求的目标系统的过程。
业务描述
上节弄清楚系统的概念,也就是先把边界框定下来,那么我们要实现的无非就是以上类别的系统。自然系统是天然形成的,或者你愿意的话也可以认为是盘古开天辟地形成的,那也可以归为人为系统。我这么说的原因是尝试把视角从软件这个领域往更加宏观的方向提升,让我们暂时忘掉软件架构师这一根深蒂固的角色。
假设现在我们想登上火星,言下之意是需要借助一套设备要把人类送到火星上,大胆一点,发挥仅存那点为数不多的物理知识储备,要设计出一套系统,能够把人类送到火星。这个时候老板就是愿意出资去火星豪华7日游的金主,那么需要一个负责人来实现这趟旅程,我们姑且把这个负责人就称为登火旅行系统架构师(叫总设计师也行,不需要在意这种细节)。那么这个系统架构师的工作,就是把登陆火星的一系列需求和目标转化成为足于支撑登陆火星庞大工程的系统架构。
根据系统总览提到的问题,先一一作答。
维度 |
问题 |
方案 |
性质 |
这件事是否合法合规? |
必须确认旅客人身安全 |
受众 |
这件事情最终谁是受益方? |
主体是金主,参加系统建设的供应商 |
利益 |
这件事做完能带来什么收益? |
美好的旅行回忆,提升人类航天水平 |
目标 |
要做一件什么样的事情? |
火星旅行,把人安全送到火星再安全送回来 |
需求 |
怎样把这件事合理的列举出来? |
人身安全 住的舒服 吃的美味 少花点钱 旅程快点 最好下次能大幅减少成本 全程跟拍 带回纪念品 |
抽象 |
怎样把这件事的主线说明清楚? |
输出业务架构/概念架构/系统架构 |
设计 |
选择什么工具把这件事实现出来? |
技术选型组合 |
方向 |
这件事是否违背了我们的初衷 |
不断验证测试 |
由于人命关天,这项工作看起来是挺复杂的,初次接到这个单子时我内心是彷徨的。但是回答了以上问题后,感觉明朗了不少,我们在完成系统性质,受众,利益和目标的分析和解答后,才能进入到系统的架构阶段。首先对以上提到的需求,我们先用动画片里面的简单画面为基础来描绘我们的设计,然后大致根据能想到的过程完成初次业务流程的描述。
业务流程画图元素:火箭,机舱,地球,火星,来回,基础功能(安全,舒适,成本)
通过以上的描述,基本涵盖了火星旅程的四个阶段:登机,航行,下机游玩,返程,这本质上跟我们平时搭个飞的去趟浪漫的土耳其也是差不多的。而在此之前我们脑海里可能还是一片混沌,沉溺在登陆火星这项浩瀚的工程而不知道从而入手。从混沌到开始有点头绪,其实无形中已经完成了一次建模,我们称为业务建模。翻回去查阅系统总览的表格,其实我们已经把需求这个维度大致列举出来了,把登陆火星的几大领域给分离开来了。那么接下来就是要把登陆火星这个项目的主线给说明清楚。
概念抽象
怎样把这件事的主线说明清楚?滔滔不绝的把一件事情讲完其实反而是很难讲明白,除非这件事情本身足够非常简单的。那么就需要抓重点的来说,这个时候就需要一个叫做“概念”的工具。
概念是抽象的、普遍的想法,是充当指明实体、事件或关系的范畴或类的实体。
简单来说,概念就是用简单的一个词汇,就可以让在坐的大家都能准确无误的理解这个词汇所表达的含义。这个是语言独特的魅力,可以说有个概念这个武器,才有了人类多次工业革命的文明大爆发。有了“概念”这个工具,再对概念进行组合,会爆发出无穷的生产力。
这里穿插讲一下概念的应用,比“傅立叶级数”这个概念,我敢打赌有80%的人不知道所谓何物,但是没关系,我们并不是要来科普这个概念,先根据百度百科来看看这个概念的描述:
若在整个数轴上: 且等式右边级数一致收敛,则有如下关系式: 一般地说,若 是以 为周期且在上可积的函数 ,则按上式计算出的称为函数(关于三角函数系)的傅里叶系数,以的傅里叶系数为系数的三角级数称为(关于三角函数系)的傅里叶级数,记作: 其中,记号“”表示上式右边是左边函数的傅里叶级数
系统落地
4.3架构思维
架构目标
架构过程
-
确定系统实体对象和预期功能 -
抽象系统实体之间的关系,功能与实体的关系 -
划定系统的边界和外部环境的关系 -
预测系统带来的效果
-
经验 -
实验 -
建模 -
推理
系统思维
-
理解系统是什么 -
预测系统的走向 -
为决策提供知识支持
5.系统分析
系统分析,旨在研究特定系统结构中各部分的相互作用,系统的对外接口与界面,以及该系统整体的行为、功能和局限,从而为系统未来的变迁与有关决策提供参考和依据。系统分析的经常目标之一,在于改善决策过程及系统性能,以期达到系统的整体最优。
结构是指在一个系统或者材料之中,互相关联的元素的排列、组织关系
-
体系归纳 -
层级分解 -
逻辑关系 -
自顶向下 -
自底向上 -
由外向内 -
由内而外
5.1实体分析
-
系统是什么? -
构成系统的元素有哪些? -
系统元素之间的结构是什么? -
系统的边界在哪里? -
系统的使用场景是什么?
-
文字描述 -
符号描述 -
插图 -
插画 -
示意图 -
三维图 -
透视图
分析实体
-
对实体的载体进行抽象聚类,形成对象,体现出边界 -
用适当的层次来分解架构的实体
分析关系
-
空间拓扑关系 -
连接性关系 -
地址关系 -
顺序关系 -
成员关系 -
所有权关系 -
人际关系
5.2功能分析
6.系统设计
TOGAF:框架开放组体系结构框架(The Open Group Architecture Framework,缩写:TOGAF)是一个企业架构框架,它提供了一种设计,规划,实施和管理企业信息技术架构的方法。TOGAF是一种高层设计方法。它通常被建模为四个级别:业务,应用程序,数据,和技术。
-
业务架构:突出了架构治理、架构流程、架构组织结构、架构信息需求以及架构产品等方面 -
数据架构:定义了组织中架构连续体和架构资源库的结构 -
应用架构:描述了用于支持此可持续架构实践的功能和服务 -
技术架构:描述了架构实践中用于支持各架构应用和企业连续体的基础设施需求和部署方式
-
描述了一种用于根据一组构建块来定义信息系统的方法 -
展示构建块如何组合在一起 -
包含一组工具 -
提供共同的词汇集合 -
包括推荐标准列表 -
包括可用于实现构建块的兼容产品列表
6.1设计工具
核心元素
-
参与者 -
用例 -
边界 -
业务实体 -
包 -
分析类 -
设计类 -
关系 -
组件 -
节点
核心视图
-
用例图 -
类图 -
包图
-
活动图 -
状态图 -
时序图 -
协作图 -
泳道图
核心模型
-
业务用例模型 -
概念用例模型 -
系统用例模型 -
业务领域模型 -
系统分析模型 -
系统设计模型 -
系统组件模型
核心流程
-
业务建模 -
系统建模 -
模型分析 -
模型实施
软件工具
-
draw.io -
StarUML -
Visual Paradigm
6.2需求分析
架构角色
系统架构师:是在信息系统研发中,负责依据需求来确定主要的技术选择、设计系统的主体框架结构,并负责搭建实施的人。 系统分析师:是在信息系统研发中,负责通过需求分析确认系统的需求,并进而形成系统产品设计的人。通常他们也会涉及可行性评估、项目管理、开发前评估、需求验证等工作。
-
了解问题领域,消除歧义 -
树立业务目标,抽象业务用例 -
完成涉众分析,发现系统主要受益者 -
划清系统边界,确立对外交互方式 -
划分优先级别,聚焦系统核心诉求 -
分析业务需求,输出业务模型 -
抽象业务概念,输出概念模型 -
推导系统架构,输出架构模型 -
负责技术选型,完成系统落地
-
企业架构师EA(Enterprise Architect) -
基础结构架构师IA(Infrastructure Architect) -
特定技术架构TSA(Technology-Specific Architect) -
解决方案架构师SA (Solution Architect)
-
现有资源评估盘点及资源编排能力 -
消除歧义分清问题主次能力 -
业务简化描述,用例抽象思维 -
通用市场法务市场领域基础常识 -
业务分析架构推导能力 -
计算机基础理论知识体系 -
通用技术栈原理认知 -
工具使用熟练,排查定位问题能力 -
技术深度广度 -
分布式高并发性能调优技能 -
产品思维
利益分析
资源评估
需求规范
-
每个软件需求是否都有唯一的标识符? -
每个软件需求都可以验证吗?(如果可能,是否可正规化,量化) -
是否对每个软件要求进行了优先排序? -
所有不稳定的软件要求是否都已标明? -
软件需求是否完整?(涵盖了所有用户要求,考虑了所有相关的输入情况) -
软件要求是否一致? -
是否明确指出了软件需求之间的重叠交叉? -
是否明确规定了初始系统状态? -
软件需求是否表达了逻辑模型, 而不是实现形式? -
软件需求是否以结构化的方式表示为抽象层次? -
是否足够清楚,逻辑模型的结构 -
软件要求是否已正式形式化? -
是否已证明软件需求的关键属性? -
所有形式化的图表材料是否都随附了充足解释性文字? -
是否针对项目团队缺乏经验的领域描述了探索性原型?
需求描述
-
满足需求,能带来什么价值,符合什么利益诉求 -
需求无法满足时,会带来什么危害,有何潜在风险 -
需求是否紧迫,必须在什么时间段内完成 -
多个需求直接是否产生耦合,完成一个需求后是否带来了新的问题 -
是否能多个备选方案来完成需求
需求采集
-
深入分析用户需求 -
搞清楚我们的客户是谁? -
定义好问题,搞清楚问题的本质,分析问题矛盾之处,我们要解决什么问题? -
我们要在多大范围内去解决问题,要解决跨度多长时间可预计的问题? -
我们的边界在哪里? -
我们的使命是什么?有了使命后再谈我们自己,愿景是什么?
6.3模型建立
模型基础
模型:是指用一个较为简单的东西来代表另一个东西。
科学模型:是科学研究中对一类研究方法的通称,使用数学公式、电脑模拟或简单的图示来表示一个简化的自然界,透过分析这个模型,以期能够进一步了解科学,包括说明、验证假说、或分析资料。
概念模型:是用一组概念来描述一个系统,或用任何代替的形式来描述一个概念,以期能进一步了解或说明事物的运作原理。具体的形式可能包括思想实验、数学模型、电脑模拟、示意图、比例模型等
业务建模:是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系,业务建模强调以体系的方式来理解、设计和构架企业信息系统
建模目标
模型分类
-
业务模型 -
概念模型 -
系统模型 -
分析模型 -
设计模型 -
物理模型
建模方法
-
领域驱动(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中最常见的一类设施是对象持久化的具体实现。
建模过程
-
用户访谈
-
领域知识
-
领域模型
6.4架构推导
架构定义
架构:对系统中实体与实体之间的关系进行抽象的描述,用于指导软件系统各个方面的设计。
架构分类
-
分层架构:MCV,六边形架构,洋葱架构 -
事件驱动架构 -
微核架构 -
微服务架构 -
云原生架构
推导架构
|
|
|
|
|
|
||||
|
||||
|
||||
|
-
演绎
-
将用例进行抽象分类成为业务模型 -
将业务模型进行IT层面的思考,增加非功能性的组件形成系统模型
-
归纳
-
将用例以及问题进行分类聚合 -
业务用例形成系统架构过程需要进行归纳 -
对行为稳定性,性能考虑的总结,归纳为通用组件
架构输出
-
方案概述:对设计方案的概括性描述 -
设计约束:包括要遵循的标准或规范,技术上依赖的假设条件等 -
技术选型:包括系统运行的软硬件环境,研发、测试的软硬件环境,编程语言,现有或开源框架、平台、模块、基础库的重用策略 -
系统结构:包括系统的网络部署结构,子系统划分。推荐用UML部署图、包图描述 -
关键技术设计:每个系统关键点不一样,但一般都会有安全设计,一些算法的设计 -
接口设计:包括协议栈,子系统间的接口数据结构,子系统间的业务流程描述。业务流程推荐用UML序列图描述。 -
数据设计:流动的数据已通过接口设计,这里描述要存储的数据。数据的组织形式不一样,比如NoSQL,NewSQL,SQL等不同类型,描述方式也会不一样。关系数据库推荐用ER模型描述顶层逻辑结构,字段表描述物理结构。 -
质量预测:对遗留缺陷率、平均无故障运行时间等质量指标进行预测,提出可能出现的缺陷和问题。
架构总结
-
自底向上:由点及面,步步为营,通过用例堆积,分类,归纳,划分,内聚,逐步扩大范围,再通过剥离,复用,从业务架构到技术架构 -
自顶向下:洞察客户背后的本质需求,定义问题,分析问题,问题分类,优先级,升层思考,一上来自带上帝视角
6.5设计规范
模型约束
设计原则
-
开闭原则(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)
7.架构落地
行业架构
技术架构
8.总结
1. 为感谢云时代架构粉丝的厚爱,赠送云时代架构系列图书《分布式服务架构原理、设计与实战》8本
2. 参与方式:扫描抽奖小程序二维码,即可参与抽奖活动!
快扫描上方二维码参与活动吧!
做互联网时代适合的架构:开放、分享、协作
求在看|求转发
以上是关于架构设计的本质(文末送书)的主要内容,如果未能解决你的问题,请参考以下文章
文末送书完整的推荐系统架构设计 《从零开始构建企业级推荐系统》
19 张图让你秒懂 Spring Cloud 全家桶!文末送书