从零构建项目认知：如何画出一张合格的系统架构图（以供应链系统为例）

你好，我是程序员小当家,正在实习的Java后端工程师。最近在准备面试复盘时，我发现我在想要描述项目时，只能说出“我做了几个接口”、“我修复了几个bug”,实现了功能,组件，但对于项目整体架构却一问三不知,我似乎也没有一个清晰的认知,只是简单停留在功能的设计书的内容。

这就像你描述自己参与建造了一栋楼，却不知道这栋楼是办公楼还是住宅楼，有几层，每层是干什么的。

今天，我就以实习的供应链系统为例，分享如何从零开始，一步步画出项目的整体架构图。这篇文章不仅记录了我的学习过程，也希望帮助其他实习生同学构建系统级的认知。

我在本文中以实习的供应链系统为例进行说明，为了便于理解，对项目细节进行了适当简化，与实际项目可能存在一些差异，但架构分析的核心思想和方法是一致的。为保护项目信息安全，我不会透露具体细节，而是基于我的经验和理解，通过通用的模块和业务场景来阐述如何分析和理解系统架构。

一、为什么面试官看重“架构理解”？

我之前的认知误区：

• “我是实习生，只要完成分配的任务就行”
• “架构是大佬们设计的，我不需要懂”
• “面试时展示我写的代码就行了”

现实是：

• 当我开始思考：“我做的这个接口在系统中起什么作用？”
• 我意识到：不能只说“处理报价数据”，更要理解它在整个业务流程中的位置
• 当我进一步思考：“那报价流程上下游是什么？数据从哪来到哪去？”
• 我发现：只有深入理解业务，才能真正明白代码的价值和意义

而画出项目的架构图,能帮我们更好的梳理项目的业务流程,以及模块之间的依赖关系.

关键点：架构理解体现你的系统思维。即使只是改bug，理解bug在整个系统中的位置，也能体现你的工程素养。

二、从零开始：四步构建整体认知

第一步：找到“一句话”定位

问题：这个系统是干什么的？

我的方法：

1. 最直接就是看项目前台网页
2. 找系统介绍或README文件,开发文档帮助新进入的人上手
3. 看接口的Controller命名.
4. 因为我们是内网开发,所有ai不能用,内网ai也不支持直接看项目,大家要是公司支持也可以去问ai.
5. 看依赖maven或是gradle,里面用到了哪些.

供应链系统的定位：

一个为企业采购方和供应商提供数字化协作的供应链管理平台

更具体的版本：

通过标准化报价流程、供应商管理、灾害响应机制，帮助企业优化采购效率、降低供应链风险的SaaS平台

对比我之前只知道：
“我做了一个报价提交接口”

第二步：识别核心业务流程

关键问题：用户在系统里完成什么核心任务？

分析过程：

1. 找入口：哪些Controller被调用最频繁？

   • Quotation...Controller → 报价相关
   • Supplier...Controller → 供应商相关
   • ImpactStudy...Controller → 灾害响应

2. 连点成线：把这些功能串联起来

   我发现系统有两个主要流程：

   流程一：采购报价流程

   采购人员创建报价请求 → 系统发送给供应商 → 供应商提交报价答复 → 采购人员审核 → 生成订单
   

   流程二：灾害响应流程

   外部系统发送灾害信息 → 系统自动分析影响 → 向受影响供应商发送调查请求 → 供应商提交回复 → 生成风险报告
   

3. 验证流程：

   • 看DTO命名：QuotationRequestDto → 报价请求
   • 看Service命名：QuotationAnswerService → 报价答复服务
   • 看数据库表：quotation_request、quotation_answer

第三步：理解系统分层架构

项目架构可能是MVC,分层架构,DDD架构,亦或是没见过的架构,我需要根据项目的实际情况,>去理解项目的架构,画出架构图.可能会遇到很复杂的架构,我们需要耐心去理解,不要被复杂的架构吓到.
大家可以从一个接口开始,根据接口的调用关系,逐步画出架构图.
但是画出架构图不等于理解架构,架构图只是一种工具,帮助我们更直观地理解系统的结构.
也不等于熟悉业务流程,架构图只是一种工具,帮助我们更直观地理解系统的结构.

我这里的项目采用的是分层架构,这是画架构图的核心！我发现系统采用实际的分层架构：

1. 表现层（Present）

负责接收请求、返回响应。

• 控制器（Controller）：如QuotationRequestController
• 数据传输对象（DTO）：定义接口的输入输出格式
• 配置：安全配置、拦截器等

2. 应用核心层（Application-Core）

处理应用级别的业务逻辑，协调各领域服务。

• 应用服务：封装复杂业务流程，协调多个领域服务
• 事件处理：管理领域事件的发布和订阅
• 命令处理：处理用户命令，执行相应的业务逻辑

3. 领域服务层（Domain-Service）

处理核心业务逻辑。

• 服务（Service）：如QuotationRequestService
• 业务对象（BO）：业务层内部的数据结构
• Mapper接口：定义数据访问操作

4. 基础设施层（Infrastructure）

处理数据持久化和外部依赖。

• 实体（Entity）：对应数据库表
• 动态查询（Example）：构建查询条件
• 外部服务集成：与第三方系统的集成

5. 数据访问层（SQL）

负责数据库操作。

• SQL语句：定义数据库操作的SQL语句
• 存储过程：数据库端的业务逻辑
• 视图定义：封装复杂查询的视图

6. 系统公共层（System-Common）

提供系统级的公共功能。

• 工具类：通用工具方法
• 异常处理：全局异常处理
• 常量定义：系统级常量
• 通用配置：跨模块的配置

我的认知升级：
之前我只知道我的代码在Service层，现在我知道：

• 上面一层是Controller（Present层）调用我
• 下面一层是我调用Mapper访问数据库（Infrastructure层和SQL层）
• 我们是承上启下的关键层，位于整个架构的核心位置

第四步：定位自己的模块

问题：我的工作在整个系统中处于什么位置？

我的分析：

1. 我负责报价模块
2. 报价模块属于采购流程
3. 在技术架构中，我主要工作在业务层

画图时的思考：

用户前端
    ↓ (HTTP请求)
表现层（Present）：QuotationController
    ↓ (调用应用服务)
应用核心层（Application-Core）：协调业务流程
    ↓ (调用领域服务)
领域服务层（Domain-Service）：我写的QuotationService ✓
    ↓ (调用Mapper)
基础设施层（Infrastructure）：数据持久化
    ↓ (执行SQL)
数据访问层（SQL）：数据库操作
    ↓ (存储数据)
数据库
    ↓ (共享功能)
系统公共层（System-Common）：通用工具和配置

三、实战：画出第一版架构图

工具选择

• 初学者：Draw.io（免费、在线）
• 常用：Lucidchart、Visio
• 代码生成：Mermaid（适合写文档）

第一步：画出分层架构骨架

解释说明：

• 用不同颜色区分层次
• 用箭头表示调用关系
• 高亮显示领域服务层（ServiceImpl实现）作为核心处理层
• 应用核心层负责协调业务流程
• 基础设施层处理数据持久化

第二步：添加业务模块

现在，把业务概念加进去：

关键改进：

• 业务模块与技术架构分离
• 我的工作在领域服务层（Domain-Service），支撑多个业务模块
• 系统公共层为所有模块提供通用功能
• 完整展示了系统的分层架构

第三步：画出完整业务架构图

结合业务流程：

这张图能回答的问题：

1. 系统有哪些核心流程？
2. 不同用户角色如何交互？
3. 我的报价模块连接了哪些上下游？

四、从“知道”到“验证”：自我理解测试

自我验证问题

1. 整体架构理解（30秒）

你能一句话概括项目的架构吗？

示例回答：“我实习的项目是一个企业级供应链协同平台，采用分层架构，包括present、application-core、domain-service、infrastructure、sql和system-common六个层级，核心业务逻辑在domain-service层处理。”

2. 模块定位理解（1分钟）

你负责的模块在系统中处于什么位置？它的上下游是什么？

示例回答：“我负责的是报价管理模块，这是采购流程的起点。上游对接供应商管理，下游对接采购订单。具体来说，当采购员需要询价时，通过present层的接口创建报价请求，application-core层协调业务流程，domain-service层处理核心逻辑，我们校验后通过infrastructure层和sql层入库。”

3. 技术实现理解（2分钟）

你负责的模块使用了哪些技术栈？如何解决遇到的技术挑战？

示例回答：“技术上，我采用了Spring Boot+MyBatis框架。在domain-service层实现了核心业务逻辑，包括Excel模板解析、数据校验、权限控制。为了解决并发问题，我使用了乐观锁机制。系统公共层提供了通用工具类和异常处理机制。”

4. 业务价值理解（30秒）

你负责的模块为业务带来了什么价值？

示例回答：“这个模块上线后，将原本需要3天的邮件报价流程缩短到30分钟，报价准确率从85%提升到98%。”

可能的拓展问题

1. “系统中各层级之间的依赖关系是怎样的？”

   • 思考点：各层级之间的调用关系、数据流向、责任边界

2. “如果要为系统添加一个新功能，你会如何设计？”

   • 思考点：功能需求分析、技术方案设计、架构影响评估

3. “系统的性能瓶颈可能在哪里？如何优化？”

   • 思考点：数据库性能、缓存策略、并发处理、代码优化

4. “如何确保系统的可扩展性？”

   • 思考点：模块化设计、接口定义、配置管理、依赖注入

5. “系统的安全考虑有哪些？”

   • 思考点：认证授权、数据加密、输入验证、异常处理

五、我的学习心得

1. 认知转变

从“我只管写代码”到“我要理解代码在系统中的位置”。

2. 方法总结

• 自上而下：先理解业务，再理解技术
• 由外到内：从用户操作看起，逐步深入
• 抓大放小：先理解主干流程，再关注细节

3. 工具推荐

• XMind：梳理业务流程
• Draw.io：画架构图
• Mermaid：在Markdown中画图（本文所有图都是用Mermaid画的）

六、下一步学习计划

1. 深入理解数据库设计：ER图怎么画？
2. 学习分布式概念：如果系统要做成微服务，怎么拆分？
3. 性能优化思考：系统的瓶颈可能在哪里？

写在最后

画架构图不是目的，建立系统思维才是。

作为实习生，我们可能接触不到最核心的架构设计，但通过主动学习和思考，我们可以：

1. 更好地理解自己的工作价值
2. 在团队讨论中更有参与感
3. 在面试中展示超越实习生的视野

一个检查标准：
如果你能用一张图，在5分钟内向完全不懂技术的家人讲清楚你的项目是干什么的，架构是什么样的，那么你就真正理解了。

希望这篇文章对你有帮助。如果你也在实习，欢迎分享你的架构图和学习心得！

---

附录：我的学习资源

1. 《企业应用架构模式》Martin Fowler
2. 极客时间《从0开始学架构》
3. GitHub上的架构图集合：https://github.com/mehdihadeli/awesome-software-architecture

注：本文基于真实实习经历，项目细节已做脱敏处理。