前言
作为架构师,TOGAF认证是一件有价值的事情。个人在开始学习和考试之前,尝试梳理一套自己的认知体系,决定撰写本系列文章(可能存在因为个人能力和认知深度引入的错误,请读者批判的眼光去看)。
首先,我们需要搞清楚 TOGAF 是什么?TOGAF 的全称是 The Open Group Architecture Framework,顾名思义 TOGAF 是 The Open Group 组织提出的一套架构框架(Arcitecture Framework)。
那么什么是架构框架?架构和框架是两个术语,我们按照总-分-总的模式进行剖析。
概念
系统
不论是架构还是框架本身都是围绕“系统”建设这个核心衍生出来的。两者均服务于系统从0到1的落地和从1到N的迭代演化。
架构 和 框架
架构(Arcitecture) - 系统的顶层设计蓝图
-
定义
架构是系统的高层抽象设计,定义了系统的核心组件、模块划分、交互逻辑以及技术选型策略。它关注的是“做什么”和“为什么做”,而非具体实现细节。- 示例:微服务架构、分层架构、事件驱动架构。
-
核心关注点
- 功能性需求:系统如何满足业务功能(如用户登录、订单处理)。
- 非功能性需求:性能、可扩展性、安全性、容错性等。
- 技术决策:数据存储方式(SQL vs NoSQL)、通信协议(HTTP vs gRPC)等。
-
典型产出物
- 架构图(如C4模型、UML图)、设计文档、技术选型清单。
框架(Framework) - 实现架构的工具箱
-
定义
框架是可复用的代码库或开发平台,提供预置的代码结构、API和规范,帮助开发者快速实现功能。它关注的是“如何做”,即具体的编码实现。- 示例:Spring(Java)、Django(Python)、React(前端)。
-
核心特点
- 约束性:强制遵循特定编程模式(如MVC、响应式编程)。
- 开箱即用:内置通用功能(如路由、依赖注入)。
- 扩展性:允许通过插件或中间件扩展功能。
-
典型产出物
- SDK、代码模板、配置文件。
架构与框架的关系
维度 | 架构 | 框架 |
---|---|---|
抽象层级 | 高层设计(战略层) | 具体实现(战术层) |
目标 | 解决系统级问题(如拆分服务边界) | 解决开发效率问题(如减少重复代码) |
灵活性 | 灵活,可适配多种技术栈 | 约束性强,需遵循框架规则 |
决策者 | 架构师、技术负责人 | 开发团队、技术栈匹配度 |
典型交互场景:
- 架构驱动框架选型:若选择微服务架构,可能选用Spring Cloud框架实现服务治理。
- 框架影响架构设计:使用React Native框架可能导致移动端采用混合开发架构而非原生开发。
如何高效结合架构与框架
-
明确架构目标
- 优先定义非功能性需求(如高并发、低延迟),再选择支持该目标的框架。
- 示例:高并发场景下,选择Netty(异步IO框架)而非传统Servlet容器。
-
评估框架适配性
- 技术栈匹配(如Java生态优先选Spring)、社区活跃度、企业现有经验等。
- 避坑指南:避免因追求新技术而引入与架构不兼容的框架。
-
分层解耦设计
- 通过抽象接口隔离框架依赖,防止框架绑定(如用JPA规范替代直接依赖Hibernate)。
-
持续演进
- 架构可能随业务变化调整(如从单体到微服务),框架需同步升级或替换。
- 示例:从Spring MVC迁移到Spring WebFlux以支持响应式架构。
架构指引,框架实施
- 架构是方向:决定系统如何分解、组件如何协作。
- 框架是工具:提供现成能力,加速实现架构设计。
- 成功关键:在灵活性与约束性之间找到平衡,避免过度依赖框架而忽视架构设计。
小结
从系统建设视角看,我们很好的认识了架构和框架的定义。那么回归正题什么是架构框架?这里需要做一个大的转折。将上面对架构框架的认知清空。
TOGAF 是一套辅助我们做架构设计的完备的方法论和工具集合。
方法论集合:作为一套标准其必然有自己对架构等概念的定义,围绕定义的必然是一套完整的方法论。
工具集合:容易理解,不做赘述。
这里存在“递归”的味道,需要我们做一下思维模式的澄清,架构框架不在是独立和关联的认知方式;一种方便认知的方式是将其重命名为“架构的框架”,架构变成了框架的修饰词,TOGAF 就是一套来培训我们如何做架构的框架。