架构图分类
架构图的目的是把抽象的内容用图表形式出来，而根据针对人群和场景的不同，架构图又可以有如下分类：
image.png
- 业务架构：主要考虑业务模块、模块之间的交互流程及业务的未来规划
- 应用架构：主要考虑服务的复用与整合，服务分层及各服务之间的协同
- 产品架构：相对于业务的粗放流程，产品架构会更加细腻以及考虑各模块的分层和边界
- 数据架构：数据的获取，存放及使用
- 技术架构: 离程序员最近的架构设计，它不仅是系统搭建的架构图设计，还包括了结构、功能、流程、逻辑等内容，它的具体描述就是整个系统如何落地的具体实现方案
Zachman框架是什么
Zachman框架（Zachman framework）是一种逻辑结构，它可以对企业信息按照不同分类和不同角度进行表示。
Zachman框架，从横向六个角度看待企业，这个六个观点可以分为；什么内容、如何工作、什么地点、谁负责、为什么这么做（称为W5H）。
框架的列由一组工件组成，分为规划者、拥有者、设计者（架构师）、建造者、分包者、产品，或者有时表示为视点：范围上下文，业务概念，系统逻辑，技术，物理，组件组装和操作类。整体如图 26-2 TOGAF Zachman框架。
image.png
表格横向六项 代表了用于描述信息系统的某一个方面，对于任何一个事物只要在这几个基本方面对其进行清洗的解释就足够可以描述清楚。
- 数据（What，即什么内容）：什么是业务数据，信息或对象？
- 功能（How，即如何工作）：业务如何运作，即什么是业务流程？
- 网络（Where，即何处）：企业运营、部署在哪里？
- 人（Who，即何人负责）：什么人？什么是业务部门及其等级制度？
- 时间（When，即什么时间）：业务计划和工作流程是什么？什么时候执行？
- 原因（Why，即为什么做）：为什么选择的解决方案？这是怎么产生的？
表格纵向六项 代表了在信息系统构造过程中所涉及到的人在描述信息系统时所采用的视角，包括：
- 范围/规划者（Planner）：此视图描述了业务目的和策略，充当其他视图将被派生和管理的上下文。
- 业务模型/拥有者（Owner）：这是对信息系统必须在其中运作的组织的描述。
- 系统模型/设计师（Designer）：该视图概述了系统如何满足组织的信息需求。
- 技术模型/建造者（Builder）：这是系统如何实施的表示，它使特定的解决方案和技术显而易见。
- 详细表述/分包者（Sub-Contractor）：这些表示说明了某些系统元素的特定于实现的细节：在生产开始之前需要进一步说明的部分。
- 功能系统/产品（Functioning Enterprise）：在1987年的论文（《A framework for information systems architecture》）中并没有这一行的内容，实际上此行的内容也并不在架构描述的范畴的之内，不过为了使得架构Zachman框架对于架构的表述更加完备，这一行最终还是被加了进去。
根据 TOGAF 的定义，企业是具有一系列共同目标组织的集合，而架构则是为了有效地实现这一系列目标。
在实现的过程中 定义了企业的结构和运作模式的概念蓝图（SearchCIO），以及构成企业的所有关键元素和其关系的综合描述（Zachman）。通过创建、沟通和优化用以描述企业未来状态和发展的关键原则和模型以将业务愿景和战略转化成有效的企业变更的过程（Gartner）。
陪你画个架构图
简单来说，架构图就是为了达成交流共识的实现方案演示，并不一定非得拘泥于某种形式，只要你能画的清楚，讲的明白就最合适不过了。
1. 架构选型图
image.png
作用：通常在新项目开发初期，都要做一些技术选型工作。在负载、网关、架构、治理、框架、服务、数据以及环境和支撑服务上，要选择适合当前开发的技术。
2. 微服务架构图
image.png
作用：技术选型完毕后，接下来就是对于这些技术的运用。这个过程有点像搭积木一样，把每一个区域用适合此位置的积木填充进去。如果是团队初建或者是技术升级，那么这个过程还是比较复杂的，需要大量的验证。不过其实互联网的技术分层和使用已经相对稳定，搭建一个这样的微服务并不会耗费太长的时间。
3. 技术架构图
image.png
作用：技术架构图主要是对于研发层面做技术实现指导的，它可以把系统分层和实现结构划分清楚。另外一般也会把案例工程的结构拿出来一起讲解，这样可以让团队伙伴快速的进入开发。
网友评论