DDD界限上下文与模块化实现的矛盾

在构建Web应用时，使用Java的原生模块或Maven模块都无法实现有界上下文（Bounded Context）。

  1. Maven模块和Java自己模块都无法构建隐含有界上下文的模块。
  2. Maven模块在构建Web应用程序时鼓励错误的共享，如需要为每个业务上下文定义不同的模型。
  3. Spring和Spring Boot没有以模块（module-info）为目标设计，因此不适合构建模块化的应用程序。
  4. 人们对Spring Modulith的实际效果表示怀疑。

Maven模块会鼓励共享错误的内容，例如在每个有界上下文中应该是独立的模型。

虽然使用正确的多模块Maven项目可以强制实施大多数规则，并且通过使用module-info、java.util.ServiceLoader和Maven <module>可以实现这一点。

但是，Spring和Spring Boot并不是为模块（module-info）设计的，而是更适用于传统的三层应用程序。

更好的方法是将应用程序视为库，创建与技术风险相关的模块，例如数据库层和Web层，以便在需要时能够替换其中的一部分。

Spring模块 vs. Maven多模块
虽然我们可以使用module-info（又称 Java 模块）实现大部分功能，但目前 Spring 并非真正为模块信息而设计。此外，大多数 Spring 开发人员都不知道或不想进行模块所需的不幸的必要仪式。也就是说，他们想把所有东西都放在一个项目中，而不是使用 maven 多模块项目（例如多个工件）分开实现。

此外，Spring 对反射的依赖程度很高，这也让人很头疼。因此，你不得不将本不需要的东西公开，或者打开大量的包。

还有一些一致性方面的问题，部署管理和 Java 模块可能无法测试，而 ArchUnit 却能测试。