如何画好一张架构图（落地最优）

1.业务建模的通用方法

业务建模的通用方法总结

业务建模是架构设计中的一个重要过程，它不仅是一个建立模型的过程，更是对业务进行抽象和无歧义书面描述的过程。以下是业务建模的通用方法及其总结：

一、建模的本质

• 建立模型：通过对业务进行抽象，形成无歧义的书面描述。
• 共性抽象：将所有的共性进行抽象，把表征的东西概念化，并将其逻辑串联起来。
• 架构过程：业务建模和系统建模的过程实际上是架构图的产出过程。

二、业务建模的步骤

1. 信息收集

• • 来源：项目中的各种历史文档、会议纪要、招标书文件等。
  • 方法：大量收集和采纳各种信息，形成初步理解。

1. 绘制核心业务流程图

• • 表达业务：通过一张核心业务流程图表达整个业务的所有信息。
  • 全局视野：确保对整个业务有全局的理解。

1. 绘制业务功能模块图

• • 模块化表达：把业务流程图中的内容模块化、结构化、组件化。

三、业务建模的过程

1. 把书读厚

• • 大量信息输入：收集各种输入，形成对业务的全面理解。
  • 探求可能性：不断探索各种可能性，问自己“游戏地图是否全部点亮”。

1. 把书读薄

• • 归类汇总：将收集到的信息进行归类汇总，形成大图。
  • 结构化表达：通过模块化、结构化的方式，形成逻辑清晰的业务图。
  • 核心问题：问自己“边界是什么？输入输出是什么？”，明确每个模块的职责。

四、业务建模的关键假设

1. 用户导向

• • 用户是谁：明确系统的用户和参与者。
  • 解决问题：用户使用系统解决什么问题，系统提供什么功能或能力。
  • 业务场景验证：一次套入一个业务场景，验证抽象结果的正确性。

1. 系统设计

• • 主流程和分支流程：定义主流程和分支流程，确保业务逻辑的完整性。
  • 全局视野：每个模块设计时，要有全局视野，明确模块在整体系统中的位置和作用。

五、业务建模的目的

1. 达成业务共识

• • 统一认识：业务、产品、测试和研发团队都能讲一样的语言，减少沟通成本。
  • 方案设计：在同一个层次上讨论和设计方案。

1. 全局视野

• • 全局图：在做某个模块设计时，能够看到全局图，明确模块的核心问题和解决方案。
  • 避免细节陷阱：不容易陷入细节，保持对整体业务的把握。

业务建模总结

业务建模是一个从信息收集、绘制核心业务流程图和业务功能模块图，到归类汇总和结构化表达的过程。这个过程需要不断地问自己关键问题，确保对业务的全面理解和全局视野。通过业务建模，可以达成业务共识，减少沟通成本，同时保持对整体业务的把握，避免陷入细节陷阱。

业务建模的核心目的是形成逻辑清晰、结构化的业务图，确保所有参与者对业务有一致的理解，并能够在同一个层次上进行讨论和设计方案。通过这种方式，可以有效地支持业务需求和技术实现，推动系统和业务的持续发展和创新。

2.从业务建模到系统建模的过程

业务建模和系统建模是架构设计中的两个重要环节，它们之间存在紧密的联系。以下是从业务建模到系统建模的详细过程及其总结：

一、业务建模与系统建模的关系

1. 业务架构图

• • 表达业务逻辑：业务架构图展示了业务的核心流程和功能模块。
  • 信息来源：通过项目历史文档、会议纪要、RFP文档等收集信息，形成业务架构图。

1. 系统架构图

• • 映射关系：从业务架构图到系统架构图，业务功能模块映射到系统功能模块，业务流程映射到系统数据流程。
  • 职责依赖和约束：系统建模更强调职责依赖和约束关系，确保系统各部分的协调和一致。

系统建模，一定是在业务建模的基础上，是业务需求到系统模型的映射，上边三张图都能看到整体，但是视角和细节程度完全不同这张图为什么要这么画？层次如何划分？边界如何确定？

二、系统建模的过程

1. 从业务到系统的映射

• • 业务功能模块到系统功能模块：识别业务功能模块，并映射到相应的系统功能模块。
  • 业务流程到系统数据流程：将业务流程转化为系统内部的数据交互流程。

1. 系统建模的维度

• • 不同维度的图：系统架构图可以从不同维度展示，如层次关系图、功能模块图等。
  • 表达层次关系：简化信息，展示系统的层次关系和功能划分。

1. 系统建模的原则

• • 覆盖所有业务场景：设计应覆盖所有已知和未来可能的业务场景，确保系统的扩展性。
  • 实体抽取：从业务实体中抽取系统实体，识别核心实体并进行抽象。
  • 图示化表达：通过各种图示（ER图、状态图、流程图等）表达系统建模结果。

三、系统建模的关键点

1. 「剥洋葱式」的由大到小，由粗到细，覆盖所有已知和未来可能业务场景

• • 整体到局部：从整体设计到局部细化，逐步深入。
  • 粗略到精细：从粗略设计到精细化设计，确保覆盖所有业务场景。
  • 模型表述：自然语言、关系模型、时序图、状态图、流程图等等进行模型表述，充分利用业务场景不断验证模型

1. 验证和扩展性

• • 验证已知场景：根据已知场景验证设计的正确性和完整性。
  • 保留扩展性：设计应保留足够的扩展性，以应对未来的变化和需求。

1. 终极武器：处理模糊点

所有的设计/逻辑模糊的点，将所有已知场景分别套入，自己讲给自己

• • 识别模糊点：识别设计中逻辑模糊的点，进行深入分析和验证。
  • 避免重构风险：模糊点往往是未来重构的起点，需特别关注和解决。

四、实例分析

1. 业务架构图

• • 业务核心流程图：展示业务的核心流程，如奥运会票务系统的业务流程图。
  • 业务功能模块图：展示业务的功能模块和结构，如云市场的业务功能模块图。

1. 系统架构图

• • 系统层次关系图：展示系统的层次关系和各层次的功能。
  • 系统功能模块图：展示系统支持业务场景的功能模块和交互关系。

五、总结

业务建模和系统建模是架构设计的重要环节，通过业务建模可以明确业务需求和流程，通过系统建模可以将业务需求转化为系统实现。系统建模强调职责依赖和约束关系，确保系统各部分的协调和一致。

在系统建模过程中，需要从业务需求出发，逐步抽取核心实体，进行抽象和验证，确保设计的正确性和扩展性。同时，需特别关注设计中的模糊点，避免未来的重构风险。

通过系统建模，可以形成清晰的系统架构图，展示系统的层次关系和功能模块，确保系统能够支持业务场景的实现和未来的扩展需求。

3.理解抽象，重新思考架构表达的角度、层次和边界

一、模是什么？

1. 业务建模

• • 定义：将业务流程和术语转化为业务模型。
  • 目的：通过抽象业务的共性和个性，形成无歧义的书面描述。

1. 系统建模

• • 定义：将业务模型转化为系统模型，表达系统的功能模块和数据流程。
  • 目的：通过实体和表述，映射业务需求，形成系统架构图。

二、建模的过程与原则

1. 归类汇总的依据

• • 归类维度：按照业务的核心功能和流程进行归类。
  • 判断标准：通过不断问自己“客户是谁？核心诉求是什么？”来确定归类的正确性。

1. 系统建模的层次划分

• • 横向划分层次：根据系统的功能模块划分层次。
  • 纵向切分模块：根据系统的职责和功能划分模块。

1. 抽象与分类

• • 抽象定义：从具体事物中抽取共性，舍弃个别和非本质的方面。
  • 抽象过程：关注共性和个性，确保抽象后的模型能够满足业务场景的需求。

三、抽象的角度与层次

1. 抽象角度

• • 角度决定抽象结果：抽象的角度决定了建模的方向和结果。
  • 多视角分析：从不同的视角（如用途、材料等）进行抽象和分类。

1. 抽象层次

1. 1. 保留当前层次所需的信息

• • • 目标：确保每个层次只保留当前所需的信息，避免信息过载和复杂度增加。
    • 方法：识别和提取当前层次的核心信息，过滤掉不相关或过于详细的信息。

1. 1. 过滤不必要的信息

• • • 目标：简化模型，确保模型的清晰性和可理解性。
    • 方法：通过逐层抽象，逐步过滤掉不必要的信息，只保留当前层次所需的核心信息。

1.抽象层次的依据

1. 1. 1. 功能需求

• • • • 依据：根据系统的功能需求，确定每个层次需要保留的信息。
      • 方法：分析系统的功能需求，提取出每个层次的核心功能和信息。

1. 1. 1. 系统复杂度

• • • • 依据：根据系统的复杂度，确定需要抽象的层次和每个层次的信息粒度。
      • 方法：评估系统的复杂度，确定需要多少层次的抽象，以及每个层次的信息粒度。

1. 1. 1. 业务逻辑

• • • • 依据：根据业务逻辑，确定每个层次需要保留的信息。
      • 方法：分析业务逻辑，提取出每个层次的核心业务信息。

1. 1. 1. 技术实现

• • • • 依据：根据技术实现的需要，确定每个层次需要保留的信息。
      • 方法：分析技术实现的需求，提取出每个层次的核心技术信息。

2.分层原则是什么？

根据共性、变化和通用性来划分层次。

常用原则：

•公用的往下走

•个性的往上走

• 下层可以独立于上层存在控制下层的变化

四、边界确定

1. 边界的定义

• • 职责划分：根据团队的分工和职责划分边界。
  • 核心实体：找到核心业务活动和实体的生命周期，确定边界。

1. 边界的变化

• • 组织变化：边界可能随着业务和组织的变化而变化。
  • 职责和功能：边界的确定依赖于抽象的角度和层次。

五、高内聚和低耦合

1. 高内聚

• • 定义：模块内部的关联程度高，功能单一化。
  • 目的：确保模块内部的自包含性和独立性。

1. 低耦合

• • 定义：模块之间的连接数量少，通信量低。
  • 目的：减少模块之间的依赖，增加系统的灵活性和可维护性。

六、抽象的方法

1. 自顶向下

• • 定义：从整体到局部，从大到小，逐层拆解。
  • 应用：系统建模通常采用自顶向下的方法。

1. 自底向上

• • 定义：从局部到整体，从小到大，逐步归纳。
  • 应用：业务建模通常采用自底向上的方法。

业务建模和系统建模的核心问题解答

1. 归类汇总的依据

• • 客户是谁？核心诉求是什么？：通过不断问自己这两个问题，确定业务信息的归类维度。

1. 系统建模的层次和模块划分

• • 抽象的角度和层次：通过抽象的角度和层次来划分系统的层次和模块，确保设计的合理性。

1. 评估设计的好坏

• • 高内聚和低耦合：通过评估模块的内聚性和耦合性，判断设计的合理性和优劣。

结论

业务建模和系统建模是架构设计中的关键步骤，通过合理的抽象和分类，可以形成逻辑清晰、结构化的业务和系统模型。抽象的角度和层次决定了建模的方向和结果，高内聚和低耦合是评估设计好坏的重要标准。通过自顶向下

如何画好一张架构图

在系统设计和架构过程中，画好一张架构图是非常重要的。架构图不仅是技术表达的工具，更是团队沟通和达成共识的桥梁。以下是关于如何画好一张架构图的详细总结：

一、架构图的目的

1. 架构图是什么

• • 定义：架构图是架构在不同层次和角度的表达，是对系统结构、组件和交互关系的可视化描述。
  • 用途：架构图用于表达系统的高层次设计、模块划分、职责依赖和数据流动。

1. 为什么要画架构图

• • 沟通桥梁：通过架构图，团队成员可以直观地理解系统结构，减少沟通中的歧义。
  • 达成共识：架构图帮助团队达成对系统设计的共识，确保所有人对系统有一致的理解。
  • 指导协作：架构图为团队内部和团队之间的协作提供指导，明确各自的职责和依赖关系。

1. 架构图给谁看

• • 团队成员：开发、测试、运维等团队成员，用于理解系统结构和职责划分。
  • 外部客户：向外部客户展示系统设计，解释系统如何满足业务需求。
  • 管理层：向管理层汇报系统设计，展示系统的整体架构和关键组件。

二、画架构图的原则

1. 明确目的

• • 核心问题：明确架构图要解决什么问题，避免为了画图而画图。
  • 目标受众：根据目标受众的需求，确定架构图的细节程度和信息完整性。

1. 抽象层次

• • 不同视角：架构图应从不同视角和抽象角度表达系统，涵盖关键方面，忽略不相关的细节。
  • 层次划分：从高层次（如系统交互图、微服务架构图）到低层次（如类图、时序图），逐层细化。

1. 一致性和清晰性

• • 图表元素：方框、箭头、颜色等图表元素应一致使用，确保其表达的含义清晰明确。
  • 术语一致：图中的术语应一致，避免不同解释带来的混淆。
  • 简化表达：避免多余的文字解释，图表应尽量自解释。

三、画架构图的步骤

1. 定义架构图的目的和受众

• • 明确目标：确定架构图的目的，是为了沟通、汇报还是指导开发。
  • 确定受众：根据受众的需求，确定架构图的细节程度和信息内容。

1. 选择合适的抽象层次

• • 高层次抽象：如系统交互图、微服务架构图，展示系统的整体结构和模块划分。
  • 低层次抽象：如类图、时序图，展示具体模块和组件的细节。

1. 绘制架构图

• • 使用一致的图表元素：确保方框、箭头、颜色等元素的一致性，清晰表达不同组件和关系。
  • 明确交互关系：通过箭头和连线，清晰展示系统组件之间的交互关系。
  • 简洁明了：避免复杂和冗长的描述，确保图表简洁明了。

1. 评估和完善架构图

• • 审视架构图：从不同视角审视架构图，确保其表达的完整性和清晰性。
  • 反馈改进：根据团队成员和受众的反馈，不断改进和完善架构图。

四、评判架构图的好坏

1. 美观和一致性

• • 颜色一致：确保图表的颜色一致，避免视觉混乱。
  • 元素一致：图表元素（如方框、箭头）的使用应一致，确保表达的含义明确。

1. 信息抽象和满足需求

• • 抽象信息：架构图应根据抽象层次表达适当的信息，避免过多或过少。
  • 满足需求：架构图应满足不同受众的需求，