简单聊聊架构设计

这个章节简单聊聊架构设计。

很多技术人员，比较热衷技术，认为技术学好了，架构设计就能手到擒来，但是我的一个观点是，脱离业务的技术都是耍流氓，不是说技术不重要，而是技术必须是服务业务的。

架构，可以说是系统的蓝图，是对系统高层次的定义和描述，在一些复杂情况下，架构可以分为面向业务的业务架构和面向计算机（系统）的软件架构。

业务架构主要是从业务方面描述软件系统，定义了系统能够实现的业务。在业务架构中，动态的内容包括业务流程、节点、输入输出，静态的内容包括业务域、业务模块、单据模型等。

软件架构有两个主要的概念流派：组成派和决策派。

• 组成派认为软件架构是计算组件以及组件之间的交互
• 决策派认为软件架构师一系列有层次的决策

这里贴一下从百度百科搜到的概念：
软件架构所指的就是说相应的系列性的抽象模式，可以为设计大型软件系统的各个方面提供相应的指导。从本质上来看，软件架构是属于一种系统草图。在软件架构所描述的对象就是直接的进行系统抽象组件构成。连接系统的各个组件之间就是做到把组件之间所存在的通讯比较明确与相对细致的实施描述。处于相应的系统实现环节，那么就会使得细化这些抽象组件成为现实的组件，比如可以是具体的某个类或者是对象。从面向对象领域进行分析，那么各个组件之前实施的连接实现往往是接口。 [1] 软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理

一般我们在进行软件开发的时候，到技术人员这里都是已经明确好了的开发需求，前面也说过了 从开始如何获取需求、了解需求、分析需求，UML用例建模，业务用例建模、概念用例建模、系统用例建模
通过这篇，我们大致从开头到软件开发之前，了解了系统的一个概貌，知道系统要实现哪些功能。接下来，我们从业务层转到计算机层，针对已经明确的需求，我们该如何在计算机中实现它。

首先，通过需求分析，我们能够确定需求的范围，得到 需求= 功能+质量+约束的细节内容

很多时候，我们的需求是很多且比较复杂的，面对这么复杂的需求，我们该如何选择，如何确定软件架构，面对这种复杂情况，我们应该确定系统的关键需求，通过关键需求来进行概念性架构设计，我们需要从众多的需求中，找到关键性需求，这些需求对系统有重大的影响，能够决定系统的成败。

这里的关键需求，是横跨了功能、质量、约束。然后通过剩余的需求，我们来验证和完善架构的设计。

概念架构设计

在确认好了需求之后，我们先进行高层设计，通过对关键需求的分析，借助鲁棒图、时序图、状态图、协作图等，对需求场景进行分解，在较高的层次分解系统，称这个步骤为概念架构设计。在概念架构设计阶段，将最关键的设计要素和交互机制确定下来，牢牢抓住重大需求、特色需求、高风险需求，有针对性的设计策略。概念架构界定系统的高层组件和他们之间的关系。这时意在对系统进行适当分解，但不陷入细节。

概念架构设计并不是细化架构，这时候不会牵扯到实际的开发语言、开发框架、接口等，在概念架构设计中，分解出来的是抽象的组件，这些组件没有接口，只有职责。
在概念设计阶段，我们首先通过鲁棒图，对关键功能进行分析，发现关键职责需要的高层抽象类，然后结合时序图、协作图、状态图，对系统进行高层的分解。

细化架构

经过概念设计之后，我们能够在较高的层次，对系统进行了分解，达成了对系统的一个初步设计，接下来，根据概念设计的内容，细化设计，一般可以通过如下5种视图进行：

1. 逻辑架构视图，主要是划分职责以及职责间如何协作，就是通过概念分析的结果对系统进行模块划分、接口定义。逻辑视图主要关注功能需求、系统职责、行为划分，不仅保罗用户可见的功能，还包括相关辅助功能。

在划分模块、子系统时，可以根据下面三个部分进行：

• 进行架构分层（水平拆分）
• 进行分区（垂直拆分，相当于是按照功能进行划分）
• 交互机制，明确各子系统、各模块之间的交互机制，如基于接口编程、消息机制或RPC调用等；

划分模块的几个原则：

• 职责不同的单元划归不同的模块
• 通用性不同的单元划归不同模块
• 需要不同开发技能的单元划归不同模块
• 兼顾工作量相对均衡，进一步划分太大的模块

在逻辑架构设计时，我们就需要定义模块之间的接口，明确各子系统、各模块之间的接口定义；
UML图静态方面可以用包图、类图、对象图描述，动态方面可以使用序列图、、状态图和活动图来描述。

2. 开发架构视图：定义了软件开发环境中，软件模块的实际组织方式，具体涉及源程序文件、配置文件、源程序包、编译后的目标文件、第三方库文件等。核心任务是：开发技术选型、程序文件划分到具体工程、程序之间的编译依赖关系。开发架构的设计着重考虑开发期质量属性，如可扩展性、可重用性、可移植性、易理解性和易测试性等。
   我们在通过逻辑架构设计得到的是一个对系统的进一步分解和协作，但是这些要落实到详细的工程代码上就需要通过开发架构在实际工程代码中体现之前的设计。
   在UML中用组件图,包图来表述. 开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
   开发视图关注系统开发过程中的质量属性，包括软件源码的组织形式、配置方式、编译打包方式及与第三方包的依赖关系等。

3. 物理架构视图：定义了“程序”如何映射（安装、部署或烧写等）到“硬件”、“数据“如何在”硬件“上保存和传递以及如何配合完成软件的可靠性、可伸缩性等要求。物理架构必须考虑功能分布和数据分布两个方面。物理架构主要有两个内容：

• 确定物理硬件配置分布方案
• 将程序映射到物理硬件

物理视图主要关注安装和部署需求，包括软件运行时的系统、网络、服务器等基础设施和相关配置以及如何利用基础设施来实现程序高可用、可伸缩等。

4. 运行架构视图，运行视图关注系统动态运行时,主要是进程以及相关的并发、同步、通信等问题。运行架构视图和开发视图的关系：开发架构视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，运行视图比较关注的正是这些运行时单元的交互问题,在UML中通常用活动图表述。
   运行视图比较关注的正是这些运行时单元的交互问题,在UML中通常用活动图表述。

运行视图关注软件运行过程中的质量属性，包括进行、线程、协程、对象之间的并发、同步、通信等问题。

5. 数据架构视图，主要设计三个内容：

• 持久化技术选型，持久化技术有文件、关系型数据库等
• 数据存储格式，如列式存储
• 数据分布策略，这是数据架构的难点，是集中式还是分布式，数据分区、复制等

数据视图主要关注数据需求，包含数据的格式、属性、关系等。
数据视图可以采用ER图来描述数据的属性、关系。

一般开发架构、运行架构用来指导开发人员开发和运行程序