迁移一个拥有五年历史的YMS：从Angular 16到21（第七部分）——整洁架构：基于领域的新文件夹结构

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

大家好，开发者社区！👋

在本系列的前六部分中，我们深入探讨了代码：独立组件、路由、信号以及无区域化。但是，如果不整理“房子”（文件夹结构），仅仅重构技术架构，就好比将法拉利的引擎安装在甲壳虫汽车的底盘上。

一个拥有五年历史的项目通常会遭受同样的通用组织弊病，今天我将展示我们如何在前端应用整洁架构和领域驱动设计的概念，以挽救我们的场站管理系统（YMS）的维护工作。

1. 经典错误：按技术类型组织

早在 Angular 14/16 时期，文献资料（以及命令行界面工具）教导我们根据文件是什么而不是它们做什么来分组文件。系统的经典结构如下所示：

src/app/
 ├── components/ （混合了按钮与业务面板）
 ├── models/     （数百个接口被扔在这里）
 ├── services/   （所有应用程序编程接口相关的内容都放在这里）
 └── views/      （页面本身）

认知噩梦：为了修改“调度”屏幕，开发人员需要打开 views 文件夹来查找超文本标记语言文件，然后跳转到 models 文件夹以理解接口，最后在 services 文件夹中搜寻应用程序编程接口调用。共同变化的代码却居住在项目中完全不同的“街区”。

2. 转折：面向领域（功能）的结构

在迁移到 Angular 21 的过程中，我们将架构转向了业务领域。黄金法则变成了：如果代码一起变化，它们就应该放在一起。

我们的新架构隔离了职责。地磅模块（现在是独立的）完全不知道 调度内部发生了什么。

src/app/
 ├── core/       （拦截器、认证、守卫 - 严格的技术层且为单例）
 ├── shared/     （按钮、管道、可复用的“哑”用户界面组件）
 └── features/   （业务领域）
      ├── agendamento/ （调度）
      │    ├── models/
      │    ├── services/
      │    └── components/
      ├── balanca/ （地磅）
      │    ├── models/
      │    ├── services/
      │    └── components/

3. 为什么这能改变游戏规则？

组织文件可能看起来像是美学上的洁癖，但在成熟的代码库和企业级系统中，这是决定在2小时内还是2天内交付一个功能的细微界限。

• 快速入职：一名初级开发人员今天加入团队，修复地磅屏幕上的一个错误。他打开 features/balanca 文件夹，理解该上下文所需的一切都在里面。
• 可扩展性与解耦：如果业务疯狂增长，我们可以轻松地将整个 balanca 文件夹提取出来，将其转换为独立的库（Angular 工作区/Nx），甚至转换为微前端，因为它不与其他领域共享“垃圾”代码。

结论

使用信号并在没有 zone.js 的情况下运行现代代码固然美妙，但从长远来看，正是文件夹架构决定了团队的速度和精神健康。

在下一篇文章（第8部分）中，我们将探讨一个通常令人头疼的根本性企业级挑战