网站开发用例说明,建设需要什么系统网站,wordpress 翻页电子书,如何增加企业网站被收录的几率简介#xff1a; 实际上架构只是系统设计里面的一个重要环节#xff0c;除了架构还包含了商业诉求#xff0c;业务建模#xff0c;系统分析#xff0c;系统设计等重要领域。本文尝试从更高视角重新审视架构设计的工作#xff0c;把架构设计的上升到系统设计的立体空间去探…简介 实际上架构只是系统设计里面的一个重要环节除了架构还包含了商业诉求业务建模系统分析系统设计等重要领域。本文尝试从更高视角重新审视架构设计的工作把架构设计的上升到系统设计的立体空间去探索最终勾勒出系统设计的全域知识体系。 作者 | 编程原理林振华
【问题】
什么是系统设计系统设计的核心是什么如何训练系统设计的思维模式有什么方法来帮助我们理解复杂的系统如何进行系统分析架构设计的本质是什么如何进行架构设计如何进行业务领域建模模型如何推导出架构设计架构设计需要遵循哪些规范
【关键词】
系统思维系统分析系统设计架构元素架构视图架构模型业务模型概念模型系统模型分析模型设计模型用例驱动领域驱动物件功能物件结构功能交互利益架构工具决策选择架构师架构图
全文概要
软件从业人员的成长路线大体是在管理线和技术线上形成突破当然也有结合起来相得益彰的。而技术上的追求架构师则是一个重要的门槛对于刚入行的程序员可能会认为架构师就是画架构图的诚然架构师很重要的一个职责是绘制架构图但这只是其中一个很小的环节而已。
实际上架构也只是系统设计里面的一个重要环节除了架构还包含了商业诉求业务建模系统分析系统设计等重要领域。本文尝试从更高视角重新审视架构设计的工作把架构设计的上升到系统设计的立体空间去探索最终勾勒出系统设计的全域知识体系。
思维分析
1. 系统总览
人类社会活动中的不管大大小小的简单抑或复杂的事物总要先出现在我们的脑海里然后再投射到现实的物理空间来。我们总是在孜孜不倦地追求美好的事物但现实存在的问题就是首先我们的脑袋也理解不了太过复杂的东西其次脑海里的想象有时候也很难真实无损的映射成现实的系统再者由于总是资源有限的我们并没有花不完的预算。
归结起来设计一个系统或者朴素的说做一件事情我们需要解决以下问题 在解决以上提出的问题前首先声明我们要实现的是一个系统而不是随意混搭的一件物品毕竟现在讨论的不是行为艺术。那么就需要先来了解系统的定义: 系统是由一组实体和实体之间关系构成的集合其功能大于各个实体功能之和。 系统可以分为自然系统和人工系统但是本文特指需要人类参与的人工系统。
自然系统
人体系统生态系统大气系统水源系统
人工系统
机械系统电子系统操作系统社会系统
2. 系统演化
上面谈到在系统设计流程主要是使用了分析思维和系统思维的结合当然人类思维还有其他的运作模式比如批判思维创新思维和发散思维等以此衍生的又是另外一套截然不同的方法论。下面我们主要分析系统设计过程中的思维活动。
通常谈起架构师就会联想到各式各样的架构图谈架构图就要搞清楚什么是架构设计那么架构设计之前是什么呢架构设计是整个系统建设的核心环节犹如设计图纸之于建筑那么重要那架构设计之上应该就是系统设计了。先搞清楚系统设计的定义 系统设计是根据系统分析的结果运用系统科学的思想和方法设计出能最大限度满足所要求的目标系统的过程。 1业务描述
上节弄清楚系统的概念也就是先把边界框定下来那么我们要实现的无非就是以上类别的系统。自然系统是天然形成的或者你愿意的话也可以认为是盘古开天辟地形成的那也可以归为人为系统。我这么说的原因是尝试把视角从软件这个领域往更加宏观的方向提升让我们暂时忘掉软件架构师这一根深蒂固的角色。
假设现在我们想登上火星言下之意是需要借助一套设备要把人类送到火星上大胆一点发挥仅存那点为数不多的物理知识储备要设计出一套系统能够把人类送到火星。这个时候老板就是愿意出资去火星豪华 7 日游的金主那么需要一个负责人来实现这趟旅程我们姑且把这个负责人就称为登火旅行系统架构师叫总设计师也行不需要在意这种细节。那么这个系统架构师的工作就是把登陆火星的一系列需求和目标转化成为足于支撑登陆火星庞大工程的系统架构。
根据系统总览提到的问题先一一作答。 由于人命关天这项工作看起来是挺复杂的初次接到这个单子时我内心是彷徨的。但是回答了以上问题后感觉明朗了不少我们在完成系统性质受众利益和目标的分析和解答后才能进入到系统的架构阶段。
首先对以上提到的需求我们先用动画片里面的简单画面为基础来描绘我们的设计然后大致根据能想到的过程完成初次业务流程的描述。
业务流程画图元素火箭机舱地球火星来回基础功能安全舒适成本 通过以上的描述基本涵盖了火星旅程的四个阶段登机航行下机游玩返程这本质上跟我们平时搭个飞的去趟浪漫的土耳其也是差不多的。而在此之前我们脑海里可能还是一片混沌沉溺在登陆火星这项浩瀚的工程而不知道从而入手。
从混沌到开始有点头绪其实无形中已经完成了一次建模我们称为业务建模。翻回去查阅系统总览的表格其实我们已经把需求这个维度大致列举出来了把登陆火星的几大领域给分离开来了。那么接下来就是要把登陆火星这个项目的主线给说明清楚。
2概念抽象
怎样把这件事的主线说明清楚滔滔不绝的把一件事情讲完其实反而是很难讲明白除非这件事情本身足够非常简单的。那么就需要抓重点的来说这个时候就需要一个叫做“概念”的工具。 概念是抽象的、普遍的想法是充当指明实体、事件或关系的范畴或类的实体。 简单来说概念就是用简单的一个词汇就可以让在坐的大家都能准确无误的理解这个词汇所表达的含义。这个是语言独特的魅力可以说有个概念这个武器才有了人类多次工业革命的文明大爆发。有了“概念”这个工具再对概念进行组合会爆发出无穷的生产力。
这里穿插讲一下概念的应用比“傅立叶级数”这个概念我敢打赌有 80% 的人不知道所谓何物但是没关系我们并不是要来科普这个概念先根据百度百科来看看这个概念的描述 先不要怕我这么说的目的不是为了让大家搞懂什么是傅立叶级数这里我们可以看出即使这么鬼畜概念也是很普通的基础概念元素组成的比如收敛公式比如三角函数比如 Σ 求和概念甚至像 123 这些阿拉伯数字。这里不得不说学数学最核心的环节就是深刻理解概念没有之一。
说回来这里的语境就是在大家都共同理解接受这些基础概念后经过一系列复杂组合的高级概念也依然能够清晰严谨的表达出来下面傅里叶级数的产生过程的动图看看就好。 好了现在我们知道了概念这个工具的重要性和功能前面我们已经列举了登陆火星要做的事情那么现在就需要精确简洁的把这件事给说清楚了这个是个困难的任务因为如果主线没有梳理清晰后面整个工程将万劫不复。
在业务建模后就是概念建模作为架构设计的输入这个阶段就需要对核心业务的充分理解同时在基础性和通用性方面的功能也需要同时考虑这个阶段需要大量的业务专家和各个领域的科学家通力协作保证对系统的理解没有偏差。经过一系列的概念抽象和组合最终输出登陆火星工程的架构图这里只是用于说明登陆火星项目同样遵循这业务-概念-架构-设计的流程不要在意架构图本身合不合理。 3系统落地
当然这还远远不够系统之所以复杂就是我们对系统总有无数更多的要求更多的功能更好的性能那么接下来就是对各个模块进行分析细化设计和实施。当然我们不会班门弄斧真的在这里去分析登陆火星的实际流程以上这个例子虽然比较粗旷但是基本也描绘了一个复杂系统建设的过程也就是从需求建模到架构的思维过程是从最原始的登火需求一步步扩展的过程。
其实我们还可以举个小一点的案例比如一个有趣的需求“赚钱”引申出来就是做一个能盈利商业项目架构有兴趣的同学可以根据这个思维模式一步一步勾画出整个流程出来相信这也是一个不错的方法也许还真能解决些许困惑。下面演示的就是登月过程宏观层面落地的步骤。 3. 架构思维
1架构目标
一直以来我听过很多人在讲架构有些人在做架构但是很难讨论出一个大家都满意的定义什么是架构师架构师需要做哪些工作或者说很少有往深的去思考只知道被称为架构师说明这个人很厉害。在我毕业的时候有个同学打趣的跟我说你们做程序的无非就是增删改查当时我竟无言以对当时脑海里浮现的是一系列工具的应用技巧比如 tomcatnginx 的使用还有对业务的翻译。
随着对业务的贴近和对计算机技术的进一步认识我重新审视“这世上的系统无非就是增删改查”这句话说对也对也不对这句话就跟计算机软件无非就是 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.ioStarUMLVisual 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 序列图描述数据设计流动的数据已通过接口设计这里描述要存储的数据数据的组织形式不一样比如 NoSQLNewSQLSQL 等不同类型描述方式也会不一样关系数据库推荐用 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 专家。本文共分为三个部分从思维讲起到系统逆向分析到后面的正向设计。从“道理术”三个角度诠释了系统架构设计的全面知识体系。
