Spring Modulith 1.0 已生产就绪且获 IDE 支持

Spring Modulith 1.0 从实验状态提升为完全支持的 Spring 项目。它通过模块和事件来构建 Spring Boot 3 应用程序。Spring Tool Suite 和 Visual Studio Code 等 IDE 现在已经提供了这个模块结构。事件发布注册中心（EPR）可以更快地完成事件保存。集成测试场景则简化了测试事件。

Spring Modulith 模块之所以会存在是因为 Java 包不分层。在下面的示例中，Java 的默认可见性向其他包隐藏了example.inventory.SomethingInventoryInternal类。但是，example.order.internal包必须是public的，因为example.order 要访问它。这就使得它对所有其他包都可见。

└─  src/main/java   ├─  example   |  └─  Application.java   ├─  example.inventory   |  ├─  InventoryManagement.java   |  └─  SomethingInventoryInternal.java   ├─  example.order   |  └─  OrderManagement.java   └─  example.order.internal      └─  SomethingOrderInternal.java

Spring Modulith 模块既不使用 Java 平台模块系统（JPMS），也不生成代码。相反，主包的每个直接子包在默认情况下都只是一个模块。在上面的例子中就是inventory和order。模块 API 由包中所有的公共类型组成。最关键的是，Spring Modulith 认为子包是模块内部的。这就解决了上面所说的example.order.internal公共包的问题。

当模块访问其他模块的内部包时，Java 仍然可以编译。但是 Spring Modulith 测试ApplicationModules.of(Application.class).verify()将会失败。Spring Modulith 使用 ArchUnit 来检测这种违规行为。

Spring Modulith 鼓励使用 Spring Framework 应用程序事件实现模块之间的通信。Spring Modulith 用 EPR 增强了这些事件，保证了事件的传递。因此，即使接收事件的模块崩溃或整个应用程序崩溃，当模块或应用程序再次运行时，注册中心仍然会传递事件。

EPR 使用 JPA、JDBC 和 MongoDB 来存储事件。在这个版本中，MongoDB 获得了自动配置的事务。使用 Spring Modulith 的应用程序可以同时使用模块和事件，也可以单独使用某个特性。

到目前为止，异步事务事件监听器需要三个注解：

@Componentclass InventoryManagement {

  @Async  @Transactional(propagation = Propagation.REQUIRES_NEW)  @TransactionalEventListener  void on(OrderCompleted event) { /*…*/ }}

1.0 版本新增注解@ApplicationModuleListener简化了上述代码：

@Componentclass InventoryManagement {

  @ApplicationModuleListener  void on(OrderCompleted event) { /*…*/ }}

测试异步事务性代码颇具挑战性。这就轮到新工具Integration Test Scenarios登场了。我们可以将它们注入到 Java 测试中，并定义好事件驱动测试的起点和预期结果。此外，在这些场景中，我们还可以自定义执行细节并定义额外的事件测试。

jMolecules为架构定义注解，如领域驱动设计的@ValueObject或@Repository，六角架构（Hexagonal Architecture）的@Port和@Adapter。Spring Modulith 1.0 检测 jMolecules 注解，生成应用程序文档，并根据注解的作用（如“Port”或“Adapter”）对类进行分组。

在2023年8月的Spring One大会上，VMware 宣布即将推出 Spring Modulith 1.1。这个新版本依赖 Spring Boot 3.2，而后者要到 2023 年 11 月 23 日才能发布。1.1 版本将支持用于事件持久化的其他数据库，如 Neo4J，为的是更好地与 Spring Data 保持一致。它还可以自动将事件发送到外部目的地。当其他应用程序对其中一些事件感兴趣时，这会很有帮助。1.1 版本将支持使用 Kafka、AMQP、甚至可能是 Redis 作为事件的外部目的地。

Oliver Drotbohm是 VMware Staff 2 的工程师，也是 Spring Modulith 背后的推动者。他向 InfoQ 介绍了 Spring Modulith。

InfoQ：Spring Modulith 推出已经有 10 个月。到目前为止，反响如何？

Oliver Drotbohm： 会议和在线社区的反馈都非常积极。让人们有点犹豫的一个主要方面是，在几天前发布之前，这个项目还一直被认为是实验性的。我们期待着社区消除顾虑并采用它。

InfoQ：在你们看来，Spring Modulith 怎么才算成功？该如何度量？

Drotbohm：当然，与所有的 Spring 项目一样，我们也在监控 Maven Central 的下载量，因为这些数值可能增长或下降。尽管如此，对于单个项目，这个数值的增长趋势通常是一个不错的使用增长率指标。我们也有 start.spring.io 的数据。考虑到 Spring Modulith 主要是面向新应用程序的，希望我们能看到好的结果。除此之外，我们也关注 GitHub 上星星的数量。

InfoQ：Spring Tool Suite 和 VS Code 已经可以读取模块结构。对于 IntelliJ 和 Eclipse 支持，你们有什么计划吗？

Drotbohm：Eclipse 通过 STS 插件提供支持。至于 IDEA，我们会和开发团队保持联系，他们正在研究。

InfoQ：目前，Spring Modulith 有两个核心的抽象概念——模块和事件。您觉得在未来的版本中还会增加其他的抽象概念吗？

Drotbohm：实际上，这两个抽象概念分别服务于尼尔·福特和马克·理查兹在《分布式系统架构》一书中所描述的软件架构的两个基本活动：“把事情拆分”（即定义应用程序的功能分解）和“将它们重新组合在一起”（定义一个编程模型，使分解出的单个部分最终能够相互交互）。应用程序模块的概念有助于实现代码库的功能结构，其中也包含了方法，确保应该分开的东西实际上是分开的。我们推荐的基于事件的应用程序集成编程模型，使这些模块可以用最终一致的方式进行交互。

 

目前，我们的重点是这两部分该如何演进，并搞清楚社区会如何使用它们，以及我们该如何响应并完善它们。计划在 1.1 M1 中引入的事件外部化机制就体现了这一点。

InfoQ：据您估计，使用模块的 Spring Modulith 应用程序占比有多少，使用事件的占比又有多少？

Drotbohm：这个我们得看下单个 Spring Modulith 构件的下载量。实验阶段的统计数据显示，模块（包括模块集成测试支持）与事件的比例是 90/10。

原文链接：

https://www.infoq.com/news/2023/08/spring-modulith-1-0/