spring

　　很多团队说模块化容易，真正难的是让依赖关系一眼可见，并且在代码演进中持续防止边界被悄悄打穿。Spring Modulith把模块依赖建模成可验证的结构，还能把它输出成图和运行时信息，适合把架构治理从口头约定变成可执行的检查与可视化产物。

　　一、Spring Modulith模块依赖怎么做到可视化

　　模块依赖的可视化不只是一张图，更重要的是让开发时能看见、评审时能对齐、上线后能追踪。建议先从团队最常用的入口做起，再逐步把图和端点纳入日常流程。

　　1、用IntelliJ IDEA直接看模块结构与依赖

　　在IntelliJ IDEA里先确认插件可用，依次打开【File】→【Settings】→【Plugins】，在Installed里搜索Spring Modulith并勾选启用，然后回到项目视图就能看到模块结构标记；想从框架视角查看模块列表，选中启动类后按Alt+7，或通过【View】→【Tool Windows】→【Structure】打开结构视图，里面会有专门的Modules节点展示模块ID、允许依赖与命名接口信息。

　　2、用Documenter生成模块依赖图与模块画布

　　在构建里引入Spring Modulith的文档能力后，可以用Documenter把模块关系输出为C4或UML风格的组件图，同时生成模块画布，用表格把每个模块的核心元素和对外接口梳理出来，适合放进团队的架构文档或代码评审附件。

　　3、把PlantUML产物变成团队能直接阅读的图

　　Documenter输出的PlantUML文本可以在IDE里用PlantUML预览插件直接打开，也可以在文档站点渲染成图片后嵌入到Asciidoc或Wiki里；这样做的关键是把生成步骤固化为固定任务，避免每个人各画各的，导致图和代码不一致。

　　4、用Actuator端点在运行时查看模块结构

　　如果你希望在测试环境或预生产环境快速确认当前包结构识别出来的模块与依赖，可以启用Spring Modulith的生产可用特性，把模块结构作为Spring Boot Actuator端点暴露出来；端点命名在演进中有过调整，常见是application-modules，接入时以你当前版本文档为准。

　　5、把可视化纳入流水线产物，形成可追溯的架构快照

　　更稳的做法是在CI里执行模块验证测试，并把Documenter生成的图和画布作为构建产物归档，评审时直接对照变化，出现跨模块调用新增时能第一时间被发现，不会等到依赖绕成网才回头补救。

　　二、Spring Modulith怎么解决模块依赖循环

　　循环依赖在模块层面意味着边界失效，Spring Modulith的验证规则明确要求模块依赖形成有向无环结构，一旦出现闭环就会在验证阶段报错。解决循环的思路不是压制报错，而是把真实的耦合关系拆开或改成更健康的交互方式。

　　1、先用验证把闭环定位到具体模块链路

　　在测试里构建ApplicationModules并调用verify方法，可以直接让违规在测试阶段失败；如果你希望先收集再筛选处理，可以用detectViolations方法拿到违规集合再决定是否抛出异常，用来做渐进式改造时很实用。

　　2、用allowedDependencies把依赖显式化，减少隐性穿透

　　循环依赖很多时候来自模块间随意引用，建议在模块根包的package-info.java里用ApplicationModule的allowedDependencies做白名单，只允许写明的模块被依赖；在IntelliJ IDEA里把光标放到allowedDependencies的引号范围内按Ctrl+Space即可补全可选依赖，空白名单代表不允许任何依赖，这能逼着团队把依赖关系说清楚。

　　3、按两类常见重构手法拆环

　　Spring Modulith维护者在讨论中给过很直白的建议，高耦合往往意味着两个模块其实应该合并，或者需要调整设计；要打断闭环，常用做法是引入第三个模块承载共享概念，让原来两个模块都依赖它，或者把导致反向依赖的类移动到更合理的模块里，从根上消掉那条回边。

　　4、用API包与命名接口做依赖倒置，避免依赖实现细节

　　Spring Modulith的验证会拒绝跨模块访问内部包，只允许通过对方模块的API包访问，这就要求你把稳定的对外契约放在API区域，把实现放在内部区域；如果某些类型需要对外开放但又不想整个模块都开放，可以用NamedInterface标注对外命名接口，再在allowedDependencies里依赖到指定接口，降低模块之间的耦合面。

　　5、把同步直连改成事件交互，消除双向调用需求

　　当闭环来自A需要调用B同时B也要回调A时，优先考虑把其中一条调用改为领域事件：A发布事件，B监听事件完成自己的工作，必要时B再发布后续事件让A感知结果，这样依赖从双向变成单向，模块边界会更稳定，也更利于后续拆分演进。

　　三、Spring Modulith依赖规则怎么固化

　　如果只解决一次循环但缺少长期约束，后续迭代很容易再次出现新的闭环或边界穿透。把规则固化成可执行的检查与可观测信息，才能让模块化长期可维护。

　　1、减少开放模块的使用，优先把模块边界做实

　　开放模块更适合迁移期过渡，长期大量使用往往说明包结构或职责划分还不够清晰；当模块边界稳定后，尽量让跨模块访问只发生在明确的API区域，避免把内部实现变成公共依赖。

　　2、开启更严格的结构校验，让违规变成可见的失败

　　在较新的版本里可以通过运行时校验开关强化结构验证，把原本只是提示的问题提升为明确的约束，配合测试一起使用能更早阻止不合规依赖进入主干。

　　3、把模块依赖校验作为合并门槛

　　把模块验证测试纳入CI并设为必过项，能把架构治理变成和单元测试一样的硬门槛，避免靠口头提醒或人工巡检维持边界，尤其适合多人并行开发的仓库。

　　4、把模块交互纳入观测，避免线上行为与结构设计脱节

　　启用Insight类能力后，既可以通过Actuator暴露模块结构信息，也能通过指标与链路追踪观察模块间交互，适合用来发现某些模块在运行期出现了异常高频的耦合调用，从而反推是否需要调整边界或引入缓存与异步化。

　　总结

　　模块依赖可视化建议优先从IDE视图与Documenter生成物入手，再补上Actuator端点做运行时核对，同时把产物纳入流水线形成可追溯的架构快照。模块依赖循环的治理关键在于让验证先把闭环暴露出来，再用allowedDependencies把依赖显式化，配合合并模块、引入第三模块、移动类与依赖倒置等手段拆环，最后用严格校验与观测把规则固化，才能在持续迭代中稳定住模块边界。