本文基于一个企业级用户模块的实战案例，系统性地阐述了三个核心开发规范与一项架构设计原则，旨在解决后端开发中常见的数据传输冗余、空指针异常、数据库性能浪费以及模块职责混乱等问题 。

一、DTO与Domain的严格分层设计

目录

参考来源

DTO（数据传输对象）与Domain（领域模型）是两类职责完全不同的实体，其核心区别在于：

• DTO：定位于接口层，用于前后端及各服务层之间的数据交互。其特点是字段精简（仅包含接口必需字段）、可附加参数校验注解、并能灵活组合多个Domain的数据以适配前端展示需求。DTO不直接映射数据库表结构，核心职责是安全、高效地传输数据 。
• Domain：定位于业务核心层，是数据库表结构的直接映射，承载完整的业务属性和规则。它专供Service层和Mapper层使用，严禁直接返回给前端，以防止敏感数据泄露。这种分层强制要求开发者在接口层通过DTO对Domain进行字段脱敏、裁剪和组装，确保了接口的安全性与清晰度 。

二、利用Java 8 Optional进行空值安全处理
针对空指针异常（NPE）这一常见问题，文章推荐使用java.util.Optional作为解决方案。其核心价值在于通过类型系统强制开发者显式处理空值情况，从而在编译期和编码阶段规避NPE风险 。

• 核心语义：Optional是一个最多只能容纳一个元素的容器，用于明确表示“值存在”或“值不存在”两种状态，与可容纳多个元素的List集合有本质区别 。
• 最佳实践：文章对比了传统null检查的易遗漏性与Optional的强制性。推荐使用Optional.ofNullable()包装可能为null的对象，并通过orElse()（提供默认值）、orElseThrow()（抛出业务异常）、map()（值转换）和ifPresent()（值存在时执行操作）等一系列链式调用来安全地访问数据，从而彻底杜绝因空值导致的运行时崩溃 。

三、应用@Transactional(readOnly = true)优化查询性能
对于纯查询业务，文章强调了使用@Transactional(readOnly = true)注解进行性能优化的重要性 。

• 优化原理：该注解向数据库声明当前事务为只读。数据库据此可进行多项优化，例如：避免记录事务日志以减少I/O开销、不加写锁以提升并发查询能力、简化事务提交流程等，从而显著降低数据库负载并提高查询吞吐量 。
• 使用规范：该注解应严格用于不包含任何数据修改（增、删、改）的纯查询方法。在实际业务中，用户信息查询、列表查询等接口是典型应用场景。同时，在读写分离架构中，该注解可指示框架自动将查询路由至从库，进一步分担主库压力 。

四、模块化架构与职责解耦
文章介绍了一种模块化架构设计，其核心特点是用户模块不包含Controller层 。

• 职责划分：系统被拆分为auth（认证）模块和user（用户）模块。auth模块对外提供所有API入口（Controller），处理登录、鉴权等逻辑；而user模块则专注于核心业务能力，仅对内提供Service、Domain和Mapper，成为一个纯粹的业务能力提供者 。
• 调用流程：完整的请求链路为：前端请求 → AuthController → AuthService → UserService → UserMapper → 数据库。这种设计实现了清晰的职责分离，避免了Controller的重复编写，将所有对外接口统一收口至认证模块，极大地提升了系统的可维护性和权限管控的便利性 。

参考来源

• 用户模块架构实战：DTO 与 Domain 分层、Optional 空值处理、事务只读优化详解