前言：为什么我没选微服务？
经常有同行问我：“你们的网优系统业务这么复杂，为什么不拆微服务？”
我的回答很直接：因为我们的核心痛点不是“并发扩展”，而是“逻辑闭环”。
在电信网络优化领域，一个“天线接反”的判断，可能同时涉及告警数据、MR（测量报告）采样、工参地理信息以及历史性能趋势。如果把这些强行拆成四个微服务，光是处理分布式事务和链路追踪，就能把团队拖垮。
但这不代表我们可以容忍代码耦合。在 通信网络优化与分析平台 的 性能 子系统中，我坚持推行一种**“物理隔离、逻辑内聚”**的单体模块化策略。今天，我想抛开那些高大上的理论，聊聊我们是怎么在 Java 生态上，把代码治理得井井有条的。
一、 拒绝“水平分层”的陷阱
传统的 MVC 教程喜欢教你：所有 Controller 放一起，所有 Service 放一起。结果就是，controllers 文件夹里塞了 50 个文件，你想找个“PCI 规划”的代码，得在一堆 Alarm,User、Log 控制器里翻半天。
在 通信网络优化与分析平台中，我强制要求按业务域垂直切分（Package by Feature）。
1. 目录结构的重构
我们不再使用扁平的包结构，而是采用垂直切片：
cn.starlinkcloud.crystal.noap.perf
├── antenna // 天线调整模块
│ ├── controller
│ │ └── AntennaFeederAdjController.java
│ ├── service
│ │ ├── AntennaService.java
│ │ └── impl
│ │ └── AntennaServiceImpl.java
│ ├── repository
│ │ └── Ant转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/x179326051/article/details/161009906
