IT技术架构职涯

架构表达方法论

DiffDay2024-04-192026-05-11

概念是人认知这个世界的基础，并用来沟通的手段。

架构定义

Linux 有架构，MySQL/JVM/业务系统也有架构。要清晰讨论架构问题，先梳理几个相似概念：模块与组件、框架与架构。

模块与组件：都是系统的组成部分。拆分角度不同，模块是逻辑单元，组件是物理单元
框架与架构：框架是提供基础功能的产品，是实现的规范；架构的定义则要复杂的多

何为架构

TOGAF：架构是结构与愿景。抽象的表示软件整体轮廓和各组件间相互关系+约束边界，是一系列决策。
IEEE：组成单元的结构+组成单元的关系+原则和指南。整体、规则、通信
是系统的结构：包括组成部分（系统、模块、组件）和他们之间的协作关系，约束规范（保证有序、高效、稳定运行），目标是对系统进行的有序构建，以符合当前业务的发展，并可快速扩展。是物理部署和软件系统演进方向的整体视图。
- 是对物/信息的功能于形式元素间的对应情况所做的分配
- 对元素间关系及元素同周边环境间关系所做的定义

TOGAF

The Open Group Architecture Framework （开放组织架构框架）

The Open Group：是国际众多知名开放性标准的制订架构和交流平台，在 1996 年由 X/Open 与OpenSoftware Foundation合并组成，提供全面和系统化的方法，厂商中立。该组织也负责维护 ArchiMate，ArchiMate 在欧洲挺流行，但在全球某些地区使用仍然有限

其架构开发方法被 ADM 被 80%的福布斯 50 强公司使用

特别为应对业务需求而设计
- 实现业务和 IT 的一致性，支持灵活变化的业务需求，满足组织的业务目标
在不同层次（业务、应用、数据、技术）上开发架构，使架构师能确保复杂的需求能被充分考虑到

战略架构

在企业架构理论中，架构是从公司战略层面，自顶向下的细化的一部分
老板关注的是战略和业务架构
- 架构愿景（战略架构），更高层次不局限于技术
- 从战略 $\longrightarrow$ 业务架构 $\longrightarrow$ 应用 | 数据 | 技术架构

flowchart LR
老板-->战略-->|业务架构师设计|业务架构BA-->|数据/应用/技术架构师设计|A(数据DA
应用AA
技术TA)

领域架构

业务架构、应用架构、数据架构、技术架构
将差距分析结果具体转为解决方案，形成一个个项目规划

价值链

价值链模型可理解为企业的核心顶层流程视图。通过该视图你再去分析企业核心的端到端业务流程，去分析跨业务域的一些流程。

你熟知的行业领域你可以直接拿出结果，对于未知领域，你必须通过详细流程分析得出结果

业务活动最终会体现到业务架构图中的业务功能单元
流程分析中的关键业务对象和数据对象，体现到数据架构中
业务架构重点是在流程，信息架构重点是在数据

timeline
   title 人身险行业L0价值链环节&L1域
   产品开发: 产品
   渠道管理: 个险渠道
         : 银保渠道
         : 电销渠道
         : 网销渠道
         : 兼代
   保单服务: 投保
         : 核保
         : 保全
         : 理赔
         : 续期
         : 风控
         : 客户保单
   客户服务: 客户运营
         : 内容运营
         : 营销活动
         : 居家养老
         : 消保
   投资管理: 投资管理
   内控管理: 内控管理
   财务企划: 财务企划
   行政品宣: 行政品宣
   科技研发: 科技研发
         : 监管报送
   人力资源管理: 人力资源管理

业务流程和 IT 系统

业务流程、业务数据、系统功能、接口集成和部署四大方面的内容是四大架构规划的基础

应用架构基本是和业务架构对应的，只有两点差异：

增加了技术平台内容和上层门户集成等内容
对业务架构中的业务域可能出现拆分&合并

大的 IT 规划一定会涉及到组合管理，项目群管理

IT 架构

架构设计是为了业务|领域问题，非功能性需求在设计考量上占据重要位置

系统生命周期长，有扩展性需求
业务流程有再造的需要

以非纯技术领域的分类看

业务架构：战略，生产力
应用架构：战术，生产关系
技术架构：装备，生产工具

针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，是软件开发者特别是架构师需深入考虑的问题

业务架构师，也会成为业务领域专家，行业专家。其对业务的定义和划分会影响组织架构和技术架构
应用架构
- 根据业务场景需要，设计应用的层次结构，制定应用规范，定义接口和数据交互协议等
- 将应用的复杂度控制在一个可接受的水平，在快速支撑业务发展的同时，保证系统的可用性和和维护性，满足非功能属性要求如性能，安全，稳定
- 应用架构和业务架构师相辅相成，业务架构决定应用架构，应用架构需适配业务架构，并随业务架构不断进化，应用架构依托技术架构最终落地
技术架构：描述需要哪些服务，哪些技术组件来实现技术服务。技术服务机组件间的交互关系
数据架构：描述数据模型，分布，数据的流向，生命周期，数据的管理等关系

技术架构

确定组成应用系统的实际运行组件（lvs、nginx、tomcat等），这些运行组件间的关系，及部署到硬件的策略
主要考虑系统的非功能特征，对系统高可用，高性能，扩展，安全，伸缩性，简洁等做系统级的把握
要求架构师具备软硬件的功能和性能过硬知识

应用架构

应用作为独立可部署的单元，为系统划分了边界，影响系统功能组织，代码开发，部署运维多方面。应用架构定义有哪些应用（逻辑模块/系统），应用间如何分工合作

明确各模块边界：逻辑分层，系统、模块定义，管件类
职责之间的协作：接口协议，协作关系
本质是通过拆分，平衡业务和技术复杂性

数据架构

指导数据库的设计，也要考虑物理架构中数据存储的设计

用什么数据库，关系型还是非关系型，是集中还是分布式存储
领域模型与数据库表的转换，表结构关系的设计（ER图）
数据类实体设计（UML类图）

业务架构（俯视）

业务服务/信息图：描述服务间流转关系和中间环节数据信息，数据架构的构思源头
功能分解图：组织所做的事情，无需陷入如何做。对业务服务进行功能分类。
建立业务服务/功能目录

含业务规划、业务模块、业务流程。对业务进行拆分，对领域模型进行设计，把现实业务转化为抽象对象。

业务架构是企业治理结构，商业能力与价值流的正式蓝图。对企业的业务流程，进行根本性的再思考和再思考的彻底性再设计，从而获得成本、质量、速度等方面业绩的巨大改善或提高。

架构合理性如何衡量

最优的架构和最合适的架构，后者更有生命力，在 TOGAF 理念中一切系统设计原则都要以解决业务问题为最终目标，完全脱离业务的基础架构是空中楼阁，容易陷入自嗨

业务价值优先，做问题的终结者
业务是否发展了，才是重要的问题

问题的前提是要搞清楚今天面临的业务量有多大，增长走势是什么样，合理的架构以能提前预见业务发展 1~2 年为宜。这样可付出合理的代价换来真正达到技术引领业务成长的效果

高于业务：是指架构提供的系统基本指标是高于业务需求的，抽象度是高于业务需求的，这对于高速发展的公司尤为重要
先于业务：是说要做面向未来的投资

以高效、稳定、安全三大目标衡量其合理性^[4]

架构图的目的

画图的目的（把信息传递出去）

解决沟通障碍
达成共识
减少歧义

在画好一个好的架构图之前，首先要明确受众，再想清楚要给他们传递什么信息

好的架构图是不需要解释的，自描述的
具备一致性和足够的准确性，能与代码相呼应

可视化建模语言对比

软件开发时，图形化可视化地传递软件架构给他人是必需能力。建模和抽象，使我们能分析和改进设计，在构建实现时提高质量。

UML，90 年代创建，提供了强大和广泛的标准符号，但缺点也在于此，复杂的符号需要花费大量时间学习和有效使用，有些工具还价格昂贵，使用困难
C4：轻量级结构化方法，用于为特定受众可视化软件架构，创建于 2011 年，与符号无关，没有指定标准的形状，颜色或样式。有限的功能集合不利于表现软件活动过程

UML 之死？

一种不满的说法是：它是为 UML 工具供应商开发的，在 UML2 中更为严重，就像有一个编译器供应商设计并推广一种通用变成语言一样，将其声明为一种行业标准，出于他们的利益而锁定所有程序员。

UML 与 J2EE 思路相同，J2EE 承担了软件的复杂性，使其不仅更复杂，且还带来了灾难性的乏味。专家不再是软件开发人员，而是官僚
不要学得太细，也不可能学得太细，UML2.5 的标准化文档差不多有 800 页，跟 Java 标准文档基本相当
图驱动的代码，并没有像倡导者所希望的那样成功
- 就像你听过 ORM 会杀死 RDB 一样，实际没有发生
- 能直接转换成可运行代码的制图投入，其付出工作量比手搓 Java 代码大得多

UML 之所以死，是因为现代软件开发不像设计飞机那样，要建立的是一个平原，大和复杂。程序员必须在平台上执行一系列实验，编程类似于进行研究，然后进行一些设计，需要更简单非形式地完成.

你可以说是敏捷间接杀死了 UML，但其实也可以说数字化需求的爆发导致其已不适应形势和环境
- 计划总是错的，过去软件项目通常大大超出预算，交付时间很晚，且还是不能满足客户的需求
- 事实证明，客户不知道他们想要什么，至少不能正确向业务分析员明确说明。通过今早交付，不仅可尽早为客户释放价值，且还可得到反馈
- 从设计繁琐的方法论转向，改变交付方式，为客户创造价值，并使员工工作效率更高
【复杂系统的图表比代码更难阅读】，像蜘蛛网的野兽 UML 创作可能很有趣，但在现实世界中绝对没用
- 太大 dUML 图会让人感到困惑和难以理解
  - 创建它会花费很多时间
  - 完成时，甚至它已经过时了，因为在此期间有人会对代码进行修改
框线式的特征可很好地解决小问题，而对于复杂的情况却毫无用处地叠在一起

UML的适用情况

描述 pattern，应用程序小部分的详细信息、以及低细节的高粒度视图。

UML 及其类似物在开发人员和团队间仍有巨大价值，以一种易于理解的方式传达复杂流程，促进共同理解

隐含着对建模的一种视角的思考，对于提升工程能力有好处，可从不同角度去理解软件系统

  classDiagram
    Animal <|-- Duck
    Animal <|-- Fish
    Animal <|-- Zebra
    Animal : +int age
    Animal : +String gender
    Animal: +isMammal()
    Animal: +mate()
    class Duck{
      +String beakColor
      +swim()
      +quack()
    }
    class Fish{
      -int sizeInFeet
      -canEat()
    }
    class Zebra{
      +bool is_wild
      +run()
    }

最精华的 UML

序列图：制定和记录工作流程

    sequenceDiagram
    participant API@{ "type": "boundary", "alias": "Public API" }
    participant Auth@{ "type": "control", "alias": "Auth Service" }
    participant DB@{ "type": "database", "alias": "User Database" }
    API->>Auth: Login request
    Auth->>DB: Query user
    DB-->>Auth: User data
    Auth-->>API: Access token

状态图：状态机简洁清晰

      ---
title: Simple sample
---
stateDiagram-v2
    [*] --> Still
    Still --> [*]

    Still --> Moving
    Moving --> Still
    Moving --> Crash
    Crash --> [*]

4+1 模型

💩没流行起来，95 年提出的时候大部分还是单体系统。4+1 的核心，无法描述系统复杂度增加下的整体业务

逻辑视图

面向用户，描述功能拆解后的组件关系，组件约束和边界。通常由组件图和类图来表示，描述功能构成，即需求

流程视图

面向系统集成人员，描述组件间的通信时序，反映系统的功能流程和数据流程，通常由时序图和流程图表示。捕获设计的并发和同步方面的问题，关注性能、可扩充性和吞吐量

流程视图举例

物理视图

面向系统工程人员，描述软件到硬件的映射，反映分布式方面，关注非功能需求。系统组件是如何部署到一组计算机节点上，指导软件系统的部署实施过程。关注系统、拓扑、安装和通信等

开发视图

描述软件在其开发环境中的静态结构，分块，分组，可见性。关注软件管理。为开发人员提供切实可行的指导，代码架构上没有把控，亦会影响全局的架构设计。例如公司内不同开发团队使用不同的技术栈或组件，公司的整体架构就会失控。

代码架构主要定义：代码单元，配置设计，框架，类库。直观的有代码的组织单元、编码规范、编码惯例、模块划分目录结构、依赖关系

场景视图

用例图描述系统参与者与功能间的关系，是 4+1 中的 1

C4 图例

国家 —> 省 —> 市 —> 道路

有些人将其看作是倒退，像要重新发明 UML 一样，但它的出发点不是这样的，其灵感来自于 UML 和 4+1 模型，但是简化版本。为了在不同抽象级别对软件系统进行建模而设计。

你可以恰当使用 UML 中的包，组件和构造型来作图。目标是在进行前期设计或追溯时，向不同类型的受众讲述不同的故事，记录现有代码库。

UML 这货的使用率在下降，就是因为它整的太复杂了。C4 模型有助于在软件架构的沟通方式中引入一些结构和原则。使用 C4 描述库，框架和 SDK？其抽象级别目标不同，库框架 SDK最好还是使用 UML 之类的东西。

为何 C4 没有涵盖业务流程，工作流，状态机，领域模型，数据模型？

其重点是构成软件系统的不同抽象级别的静态结构

kanban
  语境图
面向非技术人员
    构建的系统是什么
    谁使用？系统级别的交互
    如何融入已有的IT环境
  容器图
    [可直接部署和运行
    - 微服务
    - 应用程序
    - 数据存储
    ]
    给有技术背景的人看,描述进程级别的应用
    看清软件整体的形态和职责描述
  组件图
不是可独立部署的单元
    为软件开发如何分解交付提供框架
    给开发人员看，描述程序包相互引用依赖
  代码图
    使用对象为开发人员，是一个可选的详细级别
    通常可通过IDE工具按需生成（用基于UML的图描述实现的技术细节）
    只建议用于最重要/最复杂的组件

语境图

面向非技术人员

构建的系统是什么？
谁使用？系统级别的交互
如何融入已有的 IT 环境

容器图

可直接部署和运行
- 微服务
- 应用程序
- 数据存储
给有技术背景的人看，描述进程级别的应用
看清软件整体的形态和职责描述

组件图

不是可独立部署的单元

为软件开发如何分解交付提供了框架
给开发人员看，描述程序包相互引用依赖

代码图

使用对象是开发人员，是一个可选的详细级别
通常可通过 IDE 工具按需生成（用基于 UML 的图描述实现技术细节）
只建议应用于最重要/最复杂的组件

DDD

应用程序最主要的复杂性并不在技术上，而是来自领域本身，用户的活动或业务。

领域驱动设计的关注点在于领域和领域逻辑，以向客户（用户）提供有业务价值的领域功能。

如何应对软件复杂度？

分治：各业务领域关注自身业务能力的内聚，明确分工，不被其它领域业务侵蚀，保持清晰的限界上下文，高内聚，低耦合
关注点分离：领域模型与存储模型分析，促成业务复杂度和技术复杂度分离
统一产研语言（业务规则，领域名词），降低沟通和理解成本

流程落地

业务抽象（子域划分），领域建模（服务划分），架构设计+领域模型类设计

应用架构落地方法论

建立分层规范（如阿里COLA 的适配层 – 应用服务层 – 领域服务层 – 基础设施层）
聚合分包，功能分类

典型方法论

COLA: clean object-oriented & layered architecture
CQRS: command query responsibility segregation 读写分离，命令和查询职责分离。普通操作是将读写分两个服务来部署，有利于针对不同部分进行性能优化（瓶颈不耦合），适用于读写负荷非对称的复杂场景

IT 咨询

业务和技术双领域的实践积累
需要自我实践证悟的理论内核

存在两大问题

生搬硬套
能力强但怕讲课，虽能输出结果，但如何得到的，没有系统化总结，很难做好知识分享与转移

拆解 IT 规划

此涉及咨询方法论、流程管理和分析、信息架构，应用系统分析和设计、技术架构、项目管理和实施
业务驱动 IT 是核心，要围绕价值链分析和优化来驱动
- 一句话解释：接收市场和用户的需求，将最终的需求转变产品或服务并交付给客户的过程。
核心过程：现状分析、目标提出、差距分析、整理问题集（定义 IT 建设目标）、蓝图规划、实施分解

flowchart LR
    subgraph 业务体系架构分析
    企业业务战略和经营模式-->确认企业战略需求-->a1(定义信息战略能力)
    a2(企业信息化现状分析)
    a3(信息技术发展趋势)
    end
    subgraph 解决方案架构分析
    b1(发展信息化战略机会点)-->运营模式和业务流程-->企业信息化应用架构蓝图
    end
    a1-->b1
    a2-->b1
    a3-->b1

信息化IT咨询规划整体过程