2-2. Advanced Application Modules

애플리케이션 모듈 패키지가 하위 패키지들을 포함하고 있다면, 이를 Advanced Application Modules라고 해요.

하지만 이 경우, 2-1. Simple Application Modules 와 달리 같은 모듈끼리 참조를 하기 위한 경우에도, 모듈들을 public 으로 만들어야 해요,

Example
╰─  src/main/java
   ├─  example
   │  ╰─  Application.java
   ├─  example.inventory
   │  ├─  InventoryManagement.java
   │  ╰─  SomethingInventoryInternal.java
   ╰─  example.order
      ├─  OrderManagement.java
      └─ [internal]  <-- order 모듈 내부 디렉토리
         └─  SomethingOrderInternal.java

이 구조에서 example.order 패키지는 order 모듈의 API, 즉 Provided Interface 에요. 외부 모듈인 inventory에서 이 패키지 내부의 타입을 참조하는 것이 가능해요. 그러나 inventory 에서 example.order.internal를 참조할 경우, order 내부의 변경이 inventory 까지 전파될 수 있어요.

그러나 이를 Java Compiler 만을 사용해서는 강제로 막을 수 없어요. private 클래스로 내부 클래스를 구성하면, inventory 뿐만 아니라 order 모듈 의 provided interface 에서도 사용할 수 없고, public 의 경우에는 특정 도메인에 다른 도메인이 강하게 결합되는 것을 막을 수가 없어요.

Spring Modulith는 이 문제를 해결하기 위해 아키텍처 테스트(Verification) 기능을 제공해요. 이를 통해 컴파일러의 한계를 넘어서 모듈 간의 부적절한 참조를 잡아낼 수 있도록 도와줘요.

장점

• 모듈 내부의 복잡한 로직을 여러 하위 패키지로 쪼개어 깔끔하게 구조화할 수 있다.
• API 진입점 패키지와 내부 구현 패키지를 개념적으로 명확히 분리할 수 있다.

단점

• Java 언어 자체의 컴파일러만으로는 하위 패키지의 public 클래스에 대한 캡슐화를 보장하기 어렵다.
• 올바른 모듈 경계를 유지하기 위해 Spring Modulith의 검증(Verification) 도구 설정이 필수적이다.