软件架构如何建模

相信大家对模型一词都不陌生,但是在我们实际工作中进行软件架构设计的时候,要如何去建模呢?不知道大家是怎么去理解建模一词并能实际落地? 今天我来谈谈自己在软件架构中如何进行建模.

建模认知混沌

我们生活在一个知识与信息过载的时代, 经常会看到很多关于建模的词汇, 什么DDD建模、概念建模、业务建模等等, 有这么多关于建模的词汇, 怎么去识别它们在软件架构设计的作用呢? 其实这也是我自己学习过程中遇到的一个困难点.

我的解决思路是, 直接抛开上述各种建模的词汇, 基于第一性原理重新思考建模的含义,即在进行软件架构过程中建模的目的是什么、有哪些方法辅助我们进行建模、建模后的结果是什么? 带着这样的问题, 我们先来探讨下为什么要做架构? 对此我们可以先思考下面的问题:

  • 假如我开发一个简单的hello world程序, 我需要做架构么?
  • 假如我开发一个能支持读写100w/s的TPS的hello world程序, 那我需要做架构么?

相信通过上述的问题, 大家也看出问题, 对于第一个问题是否需要做架构呢? 在这里并没有将需求澄清清楚, 没有量化指标, 如果只是理解为开发一个hello world程序出来以满足需求, 那可以不用;

但是第二个问题是否需要做架构呢? 答案是需要. 为什么? 因为需求明确指出了100WTPS/s的读写请求, 是属于一个高性能需求, 那么要在我们的软件实现一个高性能的程序, 必然会带来一定的复杂度, 比如单机无法支持这么高的读写并发, 那么我们可能就考虑分片集群部署方式, 就单这一点, 这个时候就有些复杂了, 因此我们做架构设计是为了解决在需求澄清之后带来的复杂度.简而言之就是解决复杂度问题.

现在我们了解了架构的作用是解决复杂度问题, 那么首先关键一点是如何去识别复杂度, 通过复杂度分析来指导架构设计方案的落地.

MDA - 模型驱动架构

1) 什么是模型

建立模型的目的为了帮助我们更好地识别复杂度, 那么在建立模型之前, 我们也需要对模型要有一个理解,这里利用AI执行回答什么是模型:

模型是一种对现实世界中事物、现象或系统的简化、抽象或模拟，通常用于描述、理解、预测或优化其行为。它可以是数学公式、物理实体、计算机程序或理论框架等形式.

结合上述的含义以及我的理解, 模型就是将业务、组件以及技术复杂度进行相应的抽象简化, 模型既是设计工具, 也是验证和优化我们架构的依据,如下:

2) MDA概述

那么模型是如何驱动复杂度的识别呢? 我们可以考虑使用MDA(Model Driven Archutecture)方式驱动识别复杂度, MDA基于分阶段进行模型分层构建:

  • 首先在Case Mapping Process,即用例映射阶段包含两部分,即系统分析阶段(System Analysis) & 系统架构阶段 (System Architecture).
  • 其次是在Development Process with MDA Artifacts, 即基于MDA驱动开发过程产生对应阶段的模型, 其包含了我们需求分析阶段输出的CIM模型(Computation Independent Model)、系统架构设计阶段输出的PIM模型(Platform Independent Model)、在最后设计实现阶段输出的PSM模型(Platform Specific Model).
  • CIM模型: 通过用例分析定义核心业务流程（如电商的商品发布流程），识别业务规则复杂度
  • PIM模型: 设计模块化架构（如分层架构或事件驱动架构）, 解决逻辑分层复杂度（如订单服务与库存服务的交互边界）
  • PSM模型: 设计技术的备选方案, 选择对应的技术组合, 处理技术适配复杂度（如分布式事务的最终一致性实现）

从上述MDA驱动模型架构可以看出, 我们经历从抽象到具体的模型演变过程, 经过CIM模型 -> PIM模型 -> PSM模型的转换, 架构设计逐步从业务需求向技术过渡, 对此我基于上述的分析进行模型抽象分层并进行总结如下:

我们采用自顶向下的方法适用于让我们能够从头开始认识一个事物; 而采用自底向上的方法则是在实践过程中持续改进并提高对系统的认知,再次说明模型既是设计工具,也能提供我们在设计过程中进行验证优化并持续迭代的依据.

3) 复杂度如何优先级排序

在上述每个模型分层对应的复杂度诉求也不一样, 那么如何基于我们的复杂度需求进行排序呢? 基于架构三原则方式去考量:

  • 合适原则: 主要围绕时间、资源以及业务层面去考虑问题, 即我们设计的架构能够满足业务发展1-2年且能够在有限的资源条件下(时间 & 人力)完成.比如要搭建一个高可用系统的设计,这个时候高性能并非是我们主要关注的问题,只要高性能能够满足业务的需求,在合理的范围即可.更多的是关注高可用层面的问题.
  • 简单原则: 在软件系统有一个KISS原则, 即Keep it Simple, 我们主要围绕可靠性、可扩展性以及故障处理效率展开, 化繁为简, 因此在评估技术复杂度的时候尽量简单, 因为系统越复杂,系统可靠性就难以保证、也难以扩展,甚至故障发生的时候处理效率也会降低.
  • 演进原则: 正确评估业务需求增长的需求, 比如业务读数据峰值是100QPS/s, 那么我们完全没必要设计一个近10倍QPS的系统, 仅需要考虑2-3倍即可, 因此这块主要围绕满足当前业务需求 + 逐步迭代优化 + 部分重构改造的方式去演进.

软件架构建模总结

模型在架构设计中的作用可概括为：解构复杂性、锚定优先级、贯通实施路径。通过分层建模（CIM→PIM→PSM），其中容错模型以及成本模型是我们在建模过程中识别到相应技术复杂度而衍生出来帮助我们在架构设计与选型上做权衡.

架构师能够将模糊的业务需求转化为可执行的技术方案，同时规避过度设计风险。未来，随着模型驱动工程（MDE）和AI辅助建模的发展，模型的自动化生成与动态调优能力将进一步增强，成为应对系统复杂性的核心武器. 最后, 我画一张图用于我们软件架构建模的过程供参考:

这样当我们在做架构设计的时候, 都要回归问题本身, 目标做什么, 当前处于哪个抽象层次, 这样子就不会被所谓的模型名词给混淆, 反而会让我们在做架构设计的过程中保持清醒的目标以及职责, 更专注于目标事件本身出发.

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-03-16，如有侵权请联系 cloudcommunity@tencent 删除架构模型软件架构设计架构设计