软件工程-那些Coding常见命名

type

status

date

slug

summary

📝 主旨内容

在软件工程中，尤其是涉及事件驱动、消息处理、请求响应、任务调度等架构模式时，有一系列职责清晰、命名规范的组件术语。它们共同构成了现代系统（如 Web 框架、微服务、EDA 事件驱动架构、操作系统内核等）的核心骨架。

除了类似Dispatcher（分发器）、Handler（响应者/处理器）、Processor（处理者），还有以下常见且重要的命名模式：

✅ 一、核心角色命名（按职责分类）

英文术语	中文建议译名	核心职责	典型场景
Dispatcher	分发器 / 调度器	根据类型/规则将任务路由给合适的 Handler	MVC 框架、事件总线、命令模式
Handler	响应者 / 回调器 / 入口	接收请求或事件，协调执行（通常不包含核心业务）	HTTP 路由、GUI 事件、异常捕获
Processor	处理者 / 执行器	执行具体业务逻辑、数据转换、计算	ETL 流水线、支付引擎、风控校验
Executor	执行器	异步/并发执行任务（强调“运行”）	线程池、任务队列、命令执行
Resolver	解析器 / 决策器	解析输入、查找资源、决定下一步	GraphQL Resolver、DNS Resolver、依赖注入解析
Interceptor	拦截器	在请求/响应链中插入横切逻辑（如日志、鉴权）	Spring AOP、gRPC Interceptor
Filter	过滤器	对数据/请求进行筛选、预处理	Servlet Filter、日志过滤、消息过滤
Adapter	适配器	转换接口或协议，使不兼容系统协同工作	支付网关适配、第三方 API 封装
Router	路由器	根据路径/规则将请求导向不同处理单元	Web 路由（Express/Koa）、API Gateway
Mediator	中介者	封装对象间交互，降低耦合	聊天室、模块通信协调
Orchestrator	编排器	协调多个服务/步骤完成复杂流程	工作流引擎、Saga 模式、微服务编排
Coordinator	协调器	类似 Orchestrator，但更轻量	分布式事务协调、任务同步
Aggregator	聚合器	合并多个数据源结果为单一响应	BFF（Backend for Frontend）、API 聚合
Transformer	转换器	将数据从一种格式转为另一种	DTO 转换、XML↔JSON、Protobuf 序列化
Validator	校验器	验证数据合法性	表单校验、参数校验、业务规则检查

✅ 组合使用示例（体现协作关系）

🔁 这是一个典型的请求处理流水线（Pipeline），每个组件各司其职。

✅ 其他相关术语（进阶）

术语	说明
Listener	监听器，被动等待事件（如 `EventListener`），常与 Handler 互换，但更强调“监听”动作
Callback	回调函数，Handler 的函数式表达形式
Strategy	策略，一组可替换的算法实现（Processor 可作为 Strategy 实现）
Worker	工作者，通常指后台任务执行单元（类似 Executor + Processor）
Agent	代理/智能体，在分布式系统中代表一个自主行为单元
Facade	外观，提供统一简化接口（可能内部调用多个 Processor）

✅ 命名建议原则

动词化命名：优先使用动词名词化形式（如 Validator, Transformer），明确“做什么”；

避免泛化：少用 Manager、Util、Service（除非是 DDD 中的 Application Service）；

职责单一：一个类只做一件事，名字即文档；

保持一致性：团队内统一术语（如都用 Handler 或都用 Controller）。

📚 经典架构中的命名对照

架构模式	组件命名示例
MVC	Controller（≈ Handler）、Model、View
CQRS	CommandHandler、QueryHandler、EventHandler
EDA（事件驱动）	EventPublisher、EventSubscriber（≈ Handler）、EventProcessor
Pipeline-Filter	Filter（≈ Interceptor/Validator）、Pipeline（≈ Dispatcher）
Actor Model	Actor（≈ Handler + State）、Mailbox

二、数据对象命名规范（数据载体）

这些对象负责数据流，定义“数据长什么样、在哪用”。

在分层架构（如 DDD、Clean Architecture）中，严格区分不同层的数据对象是避免污染、提升可测试性的关键。

缩写	全称	中文名	所属层	职责	特点
PO	Persistent Object	持久化对象	数据访问层（DAO/Repository）	与数据库表结构一一对应	字段 = 表字段，含 ORM 注解（如 JPA `@Entity`）
DO	Domain Object / Data Object	领域对象 / 数据对象	领域层（Domain）	表达业务概念和规则	含业务方法、不变性约束（DDD 核心）
BO	Business Object	业务对象	业务逻辑层	封装一次完整业务操作所需的数据	可能聚合多个 PO/DO，用于 Service 层内部流转
DTO	Data Transfer Object	数据传输对象	应用层 / 跨服务边界	用于服务间或前后端数据传输	无行为，仅字段；可裁剪、合并、脱敏
VO	View Object	视图对象	表现层（Web/API）	专为前端/客户端展示定制的数据结构	字段命名符合 UI 需求（如 `userName` 而非 `user_name`）
AO	Application Object	应用对象	应用层（可选）	应用服务层内部使用的数据封装	类似 BO，但更贴近用例（Use Case）
Param / Request	—	请求参数对象	控制器层	封装 API 输入参数	通常带校验注解（如 `@Valid`）
Response	—	响应对象	控制器层	封装 API 返回结构	通常含 `code`, `message`, `data`

🔄 数据流转示例（用户注册场景）

✅ 关键原则：
禁止跨层复用对象：前端 VO ≠ 数据库 PO；
DTO/VO 必须手动转换（可用 MapStruct、ModelMapper 等工具）；
PO 不应暴露到 Controller 层（防止 SQL 注入、字段泄露）。

三、命名实践建议

1. 行为组件命名

使用 动词名词化：Validator, Transformer, Aggregator

避免模糊词：少用 Manager, Util, Helper

结合业务命名：PaymentOrchestrator, UserRegistrationValidator

2. 数据对象命名

明确后缀：UserDTO, OrderVO, ProductPO

包结构隔离：

VO/DTO 可按场景细分：

UserCreateRequest
UserDetailVO
UserSummaryDTO

3. 何时可以简化？

小型项目或原型：可合并 DTO/VO，甚至直接用 PO 返回（但需谨慎）；

内部微服务通信：若契约稳定，可用共享 DTO 库；

永远不要在生产系统中让 PO 直接序列化为 JSON！

四、常见反模式（Avoid!）

反模式	问题	正确做法
在 `Handler` 中写核心业务逻辑	职责不清，难以测试	抽象为 `Processor` 或 `Service`
用同一个 `User` 类贯穿 Controller → DB	数据污染、安全风险	分层定义 VO/DTO/PO
`DTO` 中包含业务方法	违背“纯数据”原则	方法移至 `Domain Object`
命名为 `UserService` 但只做 CRUD	名不副实	改为 `UserRepository` 或 `UserCrudService`

五、总结：命名即设计

在现代软件系统（尤其是 Web 后端、微服务、事件驱动架构）中，清晰、一致的命名不仅是代码可读性的基础，更是架构意图的直接表达。本文系统梳理了常见职责型组件（如 Handler、Processor）和数据传输对象（如 DTO、VO、PO）的命名规范、职责边界与协作关系，帮助开发者构建高内聚、低耦合、易维护的系统。

好的命名 = 自解释的架构文档。

行为组件（Handler/Processor/Dispatcher）回答：“系统如何运作？”

数据对象（VO/DTO/PO）回答：“数据如何流动？”

当你看到以下代码时，无需注释就能理解其意图：

掌握这套命名体系，不仅能写出更专业的代码，还能在技术评审、团队协作中精准传递设计思想。

📚 参考文章

《Domain-Driven Design Distilled》— Vaughn Vernon

《Clean Architecture》— Robert C. Martin

阿里巴巴 Java 开发手册（含 DTO/VO 规范）

💡

有关Notion安装或者使用上的问题，欢迎您在底部评论区留言，一起交流~