Spring Modulith module slices: start inventory without dispatch

Inspect the context boundary

The checked test is placed in the inventory package and uses ApplicationModuleTest. The context starts InventoryReservation; dispatchPlanner is absent. This proves the inventory bean can be constructed from its own module dependencies. The earlier architecture check separately rejects a compiling import into an internal package.

Drive state and event together

Reserving 19 units from a fixture balance of 47 leaves 28 and publishes one ReceiptReserved event for RECEIPT-203. An attempt to reserve 59 units for RECEIPT-211 leaves 47 and publishes no success event. The event test inspects that boundary directly.

Keep the fixture claim local

InventoryReservation stores balances in a concurrent map and publishes after the map update. The slice has no database transaction or publication registry. A crash between those two actions can lose the event. The test proves Spring wiring and in-process observation, not durable inventory accounting.

Checked excerpt

@ApplicationModuleTest
class InventoryModuleIntegrationTest {
    @Autowired InventoryReservation reservation;
    @Autowired ApplicationContext context;
}

Cost and verification

The slice starts Spring infrastructure and is slower than ApplicationModules.verify, but avoids starting unrelated module beans and remote adapters. The source kit checks the stated local behavior.

Common Mistakes

• Do not call a package scan a running module context.
• Do not infer database atomicity from an in-memory map and event publisher.
• Do not mock away inventory when inventory is the module under test.

Read next

Spring Modulith PublishedEvents: assert an accepted fact and a rejected silence, Spring Modulith module tests: distinguish structure verification from a sliced context, Spring Modulith module APIs: call the inventory root package, not its internals, Spring transaction events: run a listener after commit without claiming durability.