阿强：技术架构的拆解与技术+架构=组件+关系+约束技术

团队架构师召开了会议，会议主题是介绍技术架构的改造方案。 阿强的脑海里闪过一个模糊的建筑印象。 线框图中有密密麻麻的网格，网格中写着各种常用组件的名称。 阿强嘀咕道：“看你这次又要耍什么花招。” 投影仪中会出现一个线框图，描绘了常用的工具。 下面是IDE、gitlab、xxx构建平台、发布平台。 上面是分支管理，CI流程的各个方面，灰度策略，交付策略，动态配置等。 阿强发现这次架构图中的名词和之前的维度不一样，心里浮现了一个问号。 技术架构是怎样的？

相信很多人都有这样的疑问。 他们在工作中看到的架构图越来越多，我也迷迷糊糊地画了很多，但我还是不知道什么是技术架构。

大家对这个概念并不清楚，因为技术架构没有权威的定义。 业务服务开发、中间件开发、测试、客户端开发，不同的角色脑子里有不同的技术架构图。

什么是技术架构？技术架构拆解

技术架构=技术+架构

架构 = 组件 + 关系 + 约束

技术=解决问题的方法或装置

我们可以将技术架构理解为技术实现的架构。 还有其他类型的建筑吗？ 还有组织结构、产品结构、政治结构、法律结构、证券结构……

为什么会有这么多不同的技术架构？

因为我们做了不同维度的技术建设。 如果你做业务开发，你关心的是业务领域对应的模型、业务流程、数据存储。 这就是业务架构或者逻辑架构。 如果你是一个技术团队的负责人，你会关心如何让研发流程跑得更快，包括代码管理、开发环境、构建、测试、发布。 我们可以将这种架构称为研发架构或交付架构。 如果你是一个质量团队，你会关心如何在项目上线之前找到所有的Bug。 您已经构建了 CodeReview 流程、CI 流程、自动化测试、压力测试和性能测试。 这些可以称为研发架构或交付架构。

这些技术建设都离不开技术团队的核心使命，即开发效率高、稳定性好、**的用户体验。 我们可以根据需要将团队的技术构建划分为不同的视图描述。

RUP4+1视图模型

可以根据业务不同阶段的表现进行划分，如RUP4+1视图模型、逻辑视图、开发视图、流程视图、物理视图、用例视图/场景。

图像

架构图的作用是指导团队开发。 将技术架构划分为不同方面的观点是为了指导技术团队在不同场景下的工作。 逻辑视图可以指导业务逻辑设计，开发视图可以指导开发过程的顺利进行。 每个视图对应一个研发场景。 它们本质上是不同维度的抽象。 因此它们的组件、连接工具、承载圆素的容器、用户、关注点都是不同的。

图像

业务团队技术架构模型

还可以按照团队职责、逻辑架构、物理架构、研发架构、质量架构、决策架构来划分。

图像

客户端技术架构模型

如果只是描述客户端技术架构，一张图就可以描述清楚。

图像

参考

RUP4+1模型

C4型号