Java项目长期可维护的核心是清晰、稳定、有约束的业务域分层结构：按用户、订单等业务域划分子模块，各模块内含API、Application、Domain、Infrastructure四层，模块间通过接口或事件通信，Domain层承载业务规则，Infrastructure隔离技术细节，Maven多模块支撑CI/CD与环境隔离。
Java项目要长期可维护，核心不是堆技术，而是靠清晰、稳定、有约束的分层结构。它不追求“最先进”，而强调职责分明、边界清晰、修改影响可控。
按业务能力划分子模块，而非单纯按技术分层
传统“controller-service-dao”全项目一把抓的方式，在中大型项目里容易导致模块耦合、复用困难、团队协作低效。建议先按业务域（如用户、订单、支付）切分独立子模块，每个子模块内部再遵循经典分层：
- 每个业务模块自包含接口（API）、应用逻辑（Application）、领域模型（Domain）、数据访问（Infrastructure）四层，对外只暴露明确的API包
- 模块间通信走定义好的接口或事件，禁止跨模块直接调用对方的Service或Mapper
- 共用基础能力（如日志、异常处理、通用DTO）抽成独立的
common模块，被其他模块以Maven依赖方式引入，不反向依赖
领域模型要真正承载业务规则，而非仅作数据搬运工
很多项目把Entity当DTO用，Service里塞满if-else和SQL拼接，导致业务逻辑散落、难以测试、改一处崩一片。Domain层应成为业务核心：
- Entity封装状态与行为，比如
Order.cancel()内校验是否可取消、触发退款逻辑，而不是在Service里写一堆判断 - 值对象（VO）、领域服务（Domain Service）用于表达无法归属单个实体的业务操作，如“计算优惠后价格”可设计为
PricingService - 避免让DAO层或Controller直接操作Entity；Repository接口定义在Domain层，实现放在Infrastructure层，保持领域不受技术细节污染
基础设施层严格隔离，避免技术细节泄露到上层
数据库、缓存、消息队列、HTTP客户端等属于具体实现，不应出现在Application或Domain中：
立即学习“Java免费学习笔记（深入）”；
- Infrastructure层提供统一的适配器，比如
JdbcOrderRepository实现OrderRepository接口，上层只依赖接口 - 配置、连接池、序列化等细节全部收束在该层，更换MyBatis为JOOQ或从Redis换到Caffeine，只需重写对应Adapter，其余层几乎不动
- 第三方SDK调用（如微信支付）必须包装成内部接口，隐藏签名、加解密、重试等复杂性，上层只关心“发起支付”和“支付结果”
构建与部署结构支撑快速迭代与环境隔离
结构不只是代码摆放，还要匹配CI/CD流程和运维习惯：
- 使用Maven多模块，主POM定义统一版本与插件配置，各业务模块为
jar，启动模块为独立spring-boot-starter的war或jar - 配置按环境拆分（
application-dev.yml,application-prod.yml），敏感配置通过外部配置中心（Nacos/Apollo）注入，代码中不硬编码 - 测试分层：单元测试覆盖Domain和Application层（用Mockito隔离外部依赖），集成测试验证Infrastructure对接（如用Testcontainers启动真实MySQL）
分层不是越多越好，也不是越“标准”越对。关键是在团队达成共识的前提下，让每层做什么、不能做什么、依赖谁、被谁依赖，一目了然。改需求时能快速定位到该动哪、不该碰哪，就是好结构。
