引言： 

架构设计之前准备，业务分析和需求分析

一、业务分析：

①业务分析是在系统开发之前对系统要解决的业务领域的研究过程，目的是搞清楚该业务领域的概念以及业务的运转过程；
②开发系统的目的一般是为了优化业务流程，使业务运转得更加高效、经济；
③系统的价值主要在于实施后能够帮助客户带来多少业务价值；
④不管有无系统，业务通常是不变的；

1.1 领域模型

      领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。

 领域模型用途：

①整理业务中的概念以及关系，帮助理解业务
②指导数据库设计
③指导系统功能设计
④指导开发
 

1.2 业务对象

①业务执行者  使用组织所提供的业务的人
②业务工人  提供业务的组织的内部支撑人员
③业务实体   提供业务的组织的内部信息系统

 

1.3 业务用例

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

1.4 业务流程

概念：某个业务用例的实现流程，通常用UML序列图表示

 

二、需求分析

2.1 系统上下文

概念：系统与周边用户及其他系统之间的关系

 

2.2 系统用例

概念：系统被使用的案例

分析过程：从业务流程中推导
系统用例命名规范：动词短语（例：添加权限、查询账单）

2.3 非功能性需求

可用性
性能
安全性
可扩展性
可伸缩性
可移植性
经济性

三、架构设计

1.1 架构中组件、模块、功能之间的关系

①组件是架构设计阶段考虑的单元，功能、模块是概要设计、详细设计考虑的单元
②一个组件可包含多个模块，涉及多个功能
③一个功能的实现可能需要多个组件中的相应模块来协作完成

1.2 逻辑架构设计

①将系统分解成若干逻辑组件，并建立它们之间的关系，以满足系统需求。关系分静态和动态，其中静态关系用组件图表示，动态关系用序列图表示。
②逻辑架构中，组件名称使用母语以便理解
③逻辑架构不涉及技术元素，只是纯概念上的表述
④逻辑架构的读者可以是非技术人员
⑤逻辑架构设计完成后应和系统分析师、产品经理等人员一起确认，检查是否满足需求

1.3物理架构设计

①将逻辑架构中的组件转换为技术性的物理组件，名称使用英文，在实现时应遵循这些命名
②物理组件粒度有大有小，可表现为子系统、进程、对象等多种形式
③物理架构还需要解决非功能性需求
④物理架构还要和后续设计和实现进行衔接
⑤非技术人员可能难以理解

 什么将逻辑架构中的组件转换为技术性的物理组件，名称使用英文，在实现时应遵循这些命名
物理组件粒度有大有小，可表现为子系统、进程、对象等多种形式
物理架构还需要解决非功能性需求
物理架构还要和后续设计和实现进行衔接
非技术人员可能难以理解的是设计

 设计首先是实现意图的书面表现形式，而非口头的东西

 设计是要让实现者能理解设计者的意图

 设计是要让不同的实现者做出来的东西差不多

 设计是严肃的，后续实现者不能随意偏离设计

 什么是设计

 设计首先是实现意图的书面表现形式，而非口头的东西

 设计是要让实现者能理解设计者的意图

 设计是要让不同的实现者做出来的东西差不多

 设计是严肃的，后续实现者不能随意偏离设计