企业官网建设流程全解析

• 文档
• 教程
• 后端

三层架构（3-Tier）是 Node.js 大型应用中最实用的代码组织方案之一：把每个组件（component）的代码按"入口（entry-points）—领域（domain）—数据访问（data-access）"三层物理分层，让 Express 等 Web 框架只出现在最外层的入口适配器中，从而把 HTTP、数据库等基础设施关注点与纯业务逻辑彻底隔离。读完本文，你将掌握这套目录结构的落地方式、每一层的职责边界与调用规则，并理解它为何比 MVC、Clean Architecture 更适合大多数 Node.js 服务，以及违反分层会给后续接入测试、消息队列、定时任务带来的代价。

为什么要把 Express 关进"边界"里

在 README.md 的项目实践 1.2 节中，nodebestpractices 给出的 TL;DR 非常直白：

每个组件都应包含若干"层"——一个专门存放公共关注的文件夹：entry-point（控制器所在）、domain（业务逻辑所在）、data-access。主流架构的首要原则，就是把技术关注点（如 HTTP、DB 等）与应用的纯逻辑分离，这样开发者可以专注于编写更多功能，而不必担心基础设施问题。把每个关注点放入专属文件夹，也就是所谓的3-Tier 模式，是达成这一目标最简单的方式。

这背后的痛点在于：很多开发者习惯把request/response这类 Web 对象直接传入业务逻辑层，这违背了分离原则，会让后续通过其他客户端（测试代码、定时任务、消息队列等）复用这套逻辑变得异常困难。

三层架构的目录骨架

每个组件的根部应放置 3 个文件夹，分别代表每笔事务中的公共关注点与处理阶段：

my-system ├─ apps (components) │ ├─ component-a │ ├─ entry-points │ │ ├─ api # controller comes here │ │ ├─ message-queue # message consumer comes here │ ├─ domain # features and flows: DTO, services, logic │ ├─ />
第一层：Entry-points（入口层）—— 只是一个薄适配器
职责：所有请求与流程的起点都在这里，无论是 REST API、GraphQL、消息队列、定时任务，还是其他任何通往应用的"门"。这一层的责任被刻意压到最小：
把外部载荷（例如 JSON）适配为应用内部的格式；
做第一道入参校验；
调用 domain 层的逻辑；
返回响应。
实现上通常只需要几行代码。很多人把这层代码称作"controller"，但从技术上讲，它本质上只是一个适配器（adapter）——它负责把某种协议转换成应用领域语言，除此之外不做任何业务决策。
第二层：Domain（领域层）—— 应用的核心
职责：应用流程、业务逻辑与数据都在这里。这层接收与协议无关的载荷（纯 JavaScript 对象），同样返回纯 JavaScript 对象。技术上它包含：
services（服务）；
dto / entities（数据传输对象与实体）；
调用外部服务的 clients（客户端）。
它通常还会调用>赞分享