What problem do named interfaces (@NamedInterface) solve in Spring Modulith, and how do they interact with allowedDependencies?

**The gap named interfaces fill.** Default Modulith exposure is coarse: **base-package types = public**, **everything nested = internal**. That's fine for small modules, but larger modules want internal structure (sub-packages) *and* the ability to expose a curated slice — e.g. an **SPI** other modules implement, or an **events** package — without flattening everything into one package or exposing all internals. **Declaring a named interface.** Two forms: - **Package-based:** put `@NamedInterface("spi")` in the `package-info.java` of a sub-package. All top-level types of that sub-package become part of the named interface `spi`. ```java // com/example/app/order/spi/package-info.java @org.springframework.modulith.NamedInterface("spi") package com.example.app.order.spi; ``` - **Type-based:** annotate individual types with `@NamedInterface("spi")` to group them into a named interface regardless of package. A module can have **multiple** named interfaces (e.g. `api`, `spi`, `events`). The base package itself is the **unnamed/default** named interface. **Consuming a named interface.** Other modules reference it with the double-colon syntax in their dependency declaration: ```java @ApplicationModule(allowedDependencies = { "order :: spi" }) package com.example.app.fulfillment; ``` This says fulfillment may use **only** the `spi` named interface of order — not order's default API and not other named interfaces. If fulfillment references an order type outside `spi`, `verify()` fails. You can allow several: `{ "order :: spi", "order :: events" }`. **Interaction with allowedDependencies.** - Without `allowedDependencies`, a consuming module may use any module's exposed named interfaces (default permissive) — but still not internals that aren't part of any named interface. - With `allowedDependencies`, the `module :: interface` entries precisely scope *which* interface(s) of a target module are legal. `"order"` alone means order's default (base-package) interface; `"order :: spi"` means the spi slice. **Enforcement.** Same as everything else — static, at `ApplicationModules.of(App.class).verify()` time via ArchUnit. Named interfaces change *what is exposed*; allowedDependencies changes *who may consume what*. Together they express directional, slice-level contracts. **Gotchas.** - A sub-package with **no** `@NamedInterface` is fully internal — adding structure doesn't auto-expose it. - Named-interface and module names are **strings** in `allowedDependencies`; typos resolve to 'unknown' and fail verification (not compile). - The base package is always the default interface; you can't hide it by adding named interfaces elsewhere. - Type-based named interfaces let you expose a couple of classes from an otherwise-internal package without moving them. **When to use.** Use named interfaces when a module needs real internal package structure *and* must expose more than one coherent contract (public API vs. SPI vs. published events), especially combined with `allowedDependencies` to route each consumer to the correct slice. For simple modules, the default base-package exposure is enough — don't add named interfaces prematurely.