一、问题

需要有哪些维度的视图，才能很好地表达一个软件系统的设计

组成视图

概念：表达了系统由哪些子系统、服务、组件部分构成。
原则：

• 单一化：每个服务提供单一内聚的功能集。
• 正交化：任何一个功能仅由一个服务提供，无提供多个类似功能的服务。

交互视图

概念：交互视图，表达了系统或服务与外部系统或服务的协作关系，也即：依赖与被依赖

部署视图

部署视图，表达系统的部署结构与环境。

流程视图

表达系统内部实现的功能和控制逻辑流程。

状态视图

表达系统内部管理了哪些状态以及状态的变迁转移路径。

二、架构图

概念：架构是一种整体与局部关系的抽象描述
分类：业务架构、数据架构、产品架构、应用架构、技术架构
输出的产物包括：企业战略方向图、问题域列表、业务流程图。

数据架构

主要解决三个问题：第一，系统需要什么样的数据；第二，如何存储这些数据；第三，如何进行数据架构设计。
系统需要什么样的数据：
数据是对客观事物的真实表现，企业业务过程中的所有对象的状况都可以用数据记录下来。业务运营过程中有两条重要的线索：流程和数据。业务流程离不开数据流转，业务运营状况通过数据反映。基于业务架构的端到端的流程建模过程中，会衍生出对应的业务数据对象，需要与数据架构模型对接。流程模型和数据模型对接后落实到应用层面，就形成了产品架构。

数据架构中的数据包含静态数据和动态数据。相对静态部分如元数据、业务对象数据模型、主数据、共享数据。相对动态部分如数据流转、ETL、数据全生命周期管控治理。

如何存储：

• 集中式存储
• 分布式存储

数据架构设计
数据模型最常用的视图就是 ER 图，它主要描述企业数据实体、属性和关系。

实体 (Entiy): 企业领域对象

属性 (Attribute): 领域对象的属性

联系 (RelationShip): 两个领域对象之间的关系 (1:1, 1:n 或者 m:n)

产品架构

基础的产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。

当我们打开一个系统，我们会看到一个精美的页面，一些丰富的信息、导航。这些东西会引导我们去使用这个系统。这些东西就是这个系统的组成部分，就是这个系统的功能模块。产品架构，就是将这些不同用途的功能模块围绕特定的业务目标进行分类整合。

功能模块是用户能够完成一个操作的最小粒度的完整功能。比如一个展示可购买商品的列表页、一个修改用户密码的功能。在功能模块设计过程中，需要确保用户能通过一个功能模块完整的完成一项工作，而不是半个工作。

产品架构中，功能模块是根据其相互之间的关系来组织的。一个产品中不同的功能模块之间的关系分直接关系和间接关系。只有直接关系的功能模块才会被组织到一起，形成一个子系统。那些存在间接关系的模块，会在不同的层级通过直接关系的模块产生联系。

当具有直接关系的功能模块组合成一个子系统后，解决相同问题域的子系统就形成一个功能层级。功能层级按照接近用户实操的距离程度进行从上到下，或者从左至右的划分，这就形成了产品架构的分层。

应用架构

应用架构在规划时，需要遵循以下几个原则：

简单性
体现在应用架构是否有清晰、明确的层次划分，各应用系统之间的连接关系是否简单明确，系统之间的耦合程度低。

灵活性
体现在应用架构适应业务的快速变化，不仅要求在快速增加新应用时保持现有应用架构的稳定性，还要在适应业务变化的同时主动促进业务变革。

整合性
通过应用系统之间的解耦和组合，以统一的方式对外提供一致的服务接口，从而实现应用系统之间的共享和协作。

技术架构

应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。

技术架构解决的问题包括：如何进行纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。由于应用架构体系是分层的，那么对于的技术架构体系自然也是分层的。大的分层有微服务架构分层模型，小的分层则是单个应用的技术分层框架。大的技术体系考虑清楚后，剩下的问题就是根据实际业务场景来选择具体的技术点。各个技术点的分析、方案选择，最终形成关键技术清单，关键技术清单考虑应用架构本身的分层逻辑，最终形成一个完成的技术架构图。

总之，技术架构是将产品需求转变为技术实现的过程。

三、如何画架构图

业务域分解
功能域分解
技术域分解