架构设计方法论

 

掌握一套架构方法论，掌握规范的设计方法，设计出更好、更稳定的架构设计。

概念解析

在文章开始以前须要先理解几个概念：

• 什么是方法论？
  咱们拿到一个输入，而后根据这个输入预期一个输出，把中间这个过程描述出来就是方法论。因此咱们本篇讲的架构师方法论就是架构师先拿到通过需求分析出来的输入，而后完成架构设计，这个过程就是架构设计方法论。

   

• 什么是设计？
  设计是实现意图的书面表现形式，而非口头的东西；
  设计是要让实现者能理解设计者的意图，是给别人看而非本身看；
  设计是要让不一样的实现者作出来的东西差很少；
  设计是严肃的，后续实现者不能随意偏离设计

   

• 什么是系统架构师
  做为系统架构师你须要跳出代码层面的设计，站在更加宏观的角度进行把握。
  你关注的是整个系统而不是其中的一两个查询模块，你看到的元素更多的是 ：人 、硬件 、软件 、网络。

业务分析

业务分析概述

• 业务分析是在系统开发以前对系统要解决的业务领域的研究过程，目的是搞清楚该业务领域的概念以及业务的运转过程

• 开发系统的目的通常是为了优化业务流程，使业务运转得更加高效、经济

• 系统的价值主要在于实施后可以帮助客户带来多少业务价值

• 无论有无系统，业务一般是不变的

业务分析阶段活动模型

业务分析阶段是由业务分析师 基于自身的业务知识和相似产品的参考，再结合客户、领域专家的咨询和指导输出业务分析阶段的成果，主要包括   领域模型 和 业务模型

领域模型

领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专一于分析问题领域本 身，发掘重要的业务领域概念，并创建业务领域概念之间的关系。概念比较深奥，其实说白了就是咱们把基于对业务的理解画成一个类图，并画出这些类之间的关系（面向对象），下面咱们看一个实际的领域模型而后加深一下理解。

在领域模型绘制时常常会出现下面两种典型错误：

• 将待开发系统也放在领域模型里面
  待开发系统要不要出如今领域模型中取决于你的业务离开待开发的系统能不能玩的转。举个例子：若是开发的是共享单车的信息系统，共享单车离开信息系统确定玩不转，因此这时候信息系统须要出如今领域模型。

• 概念划分不清，关系没有画到位
  好比属性画成了类，继承关系搞错

领域模型的做用

领域模型能够整理业务中的概念以及关系，帮助团队中的成员对业务的理解保持一致；日后能够指导数据库设计、系统功能设计、指导开发。

如今有种开发模式是基于UI指导开发，根据UI进行数据库数据库设计、代码编写，咱们称之为 “急功近利式” 开发模式。由于UI是系统表面性的东西，是异变的，不稳定的，这种模式下UI变化后咱们的的设计可能也须要跟着变。

而右边是基于领域驱动开发，在开发前先去思考业务的本质，先把领域层分析出来，再根据分析出来的领域层进行界面设计、架构设计、代码开发，这是由内而外的设计，这样作出来的系统就会比较稳定。

业务模型

前面讲的领域模型是基于静态的关系，要理解业务其实更多的须要从动态的角度来了解业务运转的过程，因此这时候就须要作业务模型。理解业务模型须要先理解如下几个概念：

业务对象

业务主体主要有 业务执行者、业务工人、业务实体。

要理解这三个对象，咱们首先须要知道什么是业务，业务是指一个组织能够向组织外的人提供服务。
业务执行者(Business Actor) ：组织外的人，来享受这个服务的人就称为业务执行者；
业务工人(Business worker) ：提供业务的 组织的内部支撑人员
业务实体(Business Entity) ：提供业务的 组织的内部信息系统

理解这几个概念仍是有点拗口，咱们来看看下面一张图，一个餐厅对象的业务建模

右边大的黑框是提供业务的组织，是餐厅；图的左边是个业务执行者，是顾客；而在餐厅内部又分为业务工人（领位员、点餐员、厨师等），业务实体（餐厅点餐管理系统）

咱们在作业务建模时须要注意，全部业务对象在圆圈的右下方须要有个斜线，这是一个建模规范。

业务用例

概念：组织对外提供的业务服务

一个银行是一个提供业务的组织，这就是业务用例，考察的对象是银行这个组织而不是系统。

业务流程

业务用例是最基本的定义，而要分析业务动态的过程就须要业务流程，咱们通常用时序图来表示。

餐厅现状的业务流程这时候全部的动做步骤所有靠人参与

建设系统后的业务流程

有了系统后系统能够承担一部分工做，有了系统能改善业务流程、提升价值、下降成本，这就是 建设系统的价值以及意义 ，不然就不必作系统建设了。

业务流程分析的做用

• 动态表达业务运转的过程

• 只有很好的理解了业务流程，才能设计出更好的支持该业务的系统

• 经过对比系统实施先后的流程变化，分析优化点，评估系统价值

小结

在准备作一个系统以前须要先分析业务，将业务理解清楚。理解业务既有静态的理解（领域模型）又有动态的理解（业务流程），只有将业务理解清楚才能作出良好的系统。

需求分析

需求分析是需求工程的环节，整个需求工程分为两大块

前期主要是作需求开发，包括需求调研、需求分析、需求定义；后期须要作需求管理，包括需求确认、需求跟踪、需求变动控制。

我们架构师主要聚焦在 需求分析 和 需求定义 两个环节。

需求分析阶段活动模型

需求分析阶段是由系统分析师 基于业务分析师输出的领域模型、业务模型 再结合 需求调研成果 输出需求分析阶段的成果，主要包括   系统上下文， 功能型需求（用例模型） 和 非功能性需求（性能等）。

系统上下文

系统上下文是指系统与周边用户和其它系统之间的关系

系统上下文的绘制很简单，就是将准备开发的系统画在中间，把用户和对接的周边系统画出来这就叫系统上下文。

系统用例

系统用例是指系统被使用的案例，主要是从业务流程中推导出来，系统用例的命名规范主要是使用动词短语，如：添加用户、查询话费等短语。

咱们能够对系统用例细化，如上对登记入座信息这一用例进行细化

系统用例与业务用例的区别与联系

• 业务用例是描述组织对外提供的能力，系统用例是描述系统对外提供的能力，二者考察的对象不同

• 系统用例是业务用例相应流程中对系统的一个操做

功能与用例的区别和联系

• 用例是需求分析的产物，描述的是某种用户使用系统完成什么业务

• 功能是设计阶段的产物，是根据系统用例和架构中的组件推导出来的

• 功能是静态的，用例是动态的

• 从语法角度来讲，用例是动词短语，功能是名词短语 例：用例命名（查询空位），功能命名（空位查询）

• 常见的错误：描述需求时拿出一份功能清单

非功能性需求

主要是肯定一些非功能性需求，好比：可用性、 性能、 安全性、 经济性、可扩展性、 可伸缩性、可移植性等等 可用性、性能、安全性是须要重点关注的内容，咱们后期专门拿出来说。

架构设计（重点）

前面的业务分析与需求分析通常是由其余专人来作，那么这一块的内容则是架构师的工做，须要重点关注。

在系统简单时咱们须要从 功能角度 对系统进行分解和拆分，这个时候咱们只要作下概要设计和详细设计就能够。

在复杂系统时咱们须要从 组件角度 对系统进行分解和拆分，这个时候咱们就须要作架构设计与概要设计。

组件、功能、模块

组件是架构设计阶段考虑的单元（进程级别），功能、模块是概要设计、详细设计考虑的单元；一个组件可包含多个模块，涉及多个功能；一个功能的实现可能须要多个组件中的相应模块来协做完成。

咱们用一张图来理解他们三者之间的关系 

先后端分离的一个项目从进程角度划分出三个组件，分别是web前端、后端接口服务、后台服务， 为了实现用户查询这个功能必需要在相应组件里都须要有相应的模块

一个组件里能够有多个不一样的模块，各个组件里的模块相互协做完成某一个功能

架构

若是用一句话来描述什么是架构，那应该能够这样定义：架构是系统的内部结构（组件以及它们之间的关系）还要包含系统的技术要素。作架构设计其实就是干这两件事。

架构设计有两个目标：

• 知足功能性需求

• 知足非功能性需求

架构设计阶段活动模型

架构设计阶段是由系统架构师 参照需求分析的产物（SRS），再经过对系统分析师、项目经理的咨询输出架构设计阶段的成果，主要包括   架构工做计划 、 逻辑架构、物理架构、开发组件一览表、部署组件一览表、技术选型一览表

那如何来衡量一个架构的设计好坏呢？

在设计完成时咱们能够经过设计资料的规范性以及设计思路、方案决策、技术选型的合理性来校验；
在系统实现后能够经过功能性和非功能性需求的知足程度来校验。

逻辑架构设计（非技术型）

• 将系统从非技术角度分解成若干逻辑组件，并创建它们之间的关系，以知足系统需求。关系分静态和动态，其中静态关系用组件图表示，动态关系用序 列图表示。

• 逻辑架构中，组件名称使用母语以便理解

• 逻辑架构不涉及技术元素，只是纯概念上的表述

• 逻辑架构的读者能够是非技术人员

• 逻辑架构设计完成后应和系统分析师、产品经理等人员一块儿确认，检查是否知足需求

咱们看一个典型的逻辑架构

物理架构设计（技术型）

• 将逻辑架构中的组件转换为技术性的物理组件，名称使用英文，在实现时应遵循这些命名

• 物理组件粒度有大有小，可表现为子系统、进程、对象等多种形式

• 物理架构还须要解决非功能性需求

• 物理架构还要和后续设计和实现进行衔接

• 非技术人员可能难以理解

咱们看一个典型的物理架构

小结

架构设计为系统的整体设计，决定了系统的组件划分、关键技术方案决策、技术选型 架构设计上接需求，下接进一步的设计和实现，是决定系统实现的质量、效率、成本的关键阶段

概要设计与详细设计

概要设计

概要设计阶段的主要内容是进行功能模块划分以及接口定义（接口名称、功能概要、参数、返回值）

概要设计阶段活动模型

概要设计阶段是由开发组长 基于系统用例、开发组件一览表 再结合对架构师和系统分析师的咨询输出概要设计阶段成果，主要包括  功能一览表 ， 接口说明书。

详细设计

详细设计阶段的主要内容是描述内部模块实现、界面设计以及数据库设计

详细设计阶段活动模型

详细设计阶段可能会根据工做内容进行分工，主要结合以前的产出输出详细设计阶段的成果，主要包括  界面设计 ， 模块内部设计 ， 数据库设计。

后续工程阶段

开发阶段活动模型

开发阶段主要是由开发人员结合架构设计的产物以及详细设计的产物编写相应代码。

测试阶段活动模型

测试阶段主要是由测试人员结合架构设计的产物以及详细设计的产物进行功能测试，包括功能性需求以及非功能性需求，须要对外输出 测试计划，测试用例 以及 测试报告。

部署阶段活动模型

部署阶段主要是由部署人员结合架构设计的产物以及跟开发人员的咨询进行组件部署，这一阶段须要输出部署计划、部署方案、部署手册、部署脚本、部署实施 等

运维阶段活动模型

运维阶段主要是由运维人员结合架构设计的产物进行系统运维，须要输出运维计划、运维方案、运维手册、运维脚本、运维报告 等。

 

以上，但愿对你有所帮助！

 

 

 

 

 

 

 

 

本文分享自微信公众号 - JAVA日知录（javadaily）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。