$ git checkout step/0

Run ./etc/prepare-talk.sh (Opens src/main/asciidoc/index.adoc in browser with Asciidoctor plugin installed).

Three logical application modules customer, order, inventory representing the functional blocks of our application.

The order module refers to a customer identifier (aggregate structure reference only)

ModularityTests — creates documentation based on the module conventions and verifies the general structure.

Run documentation tests of ModularityTest.

Introduce OrderManagement → Inventory dependency to invoke it from OrderManagement.complete(…).

Introduce public InventoryRepository as inventory-internal component.

Additional discussion

Application module model used for verification can be used to isolate integration tests.

Run InventoryIntegrationTests — Show log output. Component scanning and auto-configuration restricted to only the inventory package.

Run OrderIntegrationTests — The tests fails as the bean reference to Inventory cannot be satisfied

Additional discussion

Point out that OrderIntegrationTests tests basic persistence and show JPA boilerplate annotations

$ git checkout step/1

Run ModularityTests.renderDocumentation().

Application modules encapsulate internals using package private components.

Inventory exposes configuration properties that are documented in the AMC.

OrderManagement actively triggers Inventory. Order completion is a point of functional gravity that will also attract other tangential functionality: calculating rewards points for completed orders, sending confirmation emails etc. Integration is synchronous, causes the transaction to expand (violates DDD principle of aggregate being the scope of strong consistency) and increases the risk of primary business functionality to break because of failure in attached functionality.

The actually required Order parameter for Inventory.updateStock() creates a module cycle. 😣

Tests require mocks for all cross-application-module bean references.

Is there a different way to integrate the application modules?

$ git checkout step/2

Run ModularityTests.renderDocumentation().

We register a domain event from Order.complete() and implicitly publish it through the ….save(…) call on the repository.

We removed the dependency from OrderManagement to Inventory.

We changed our test case to remove the mock for Inventory and rather test for the event publication only. The side effect of the business operations ends within the module.

The event publication and listening is reflected in the generated documentation.

Integration model changed

Consistency guarantees stay the same (Inventory can break transaction)

Switch to @ApplicationEventListener

How does that change the consistency guarantees?

What if an asynchronous, transactional event listener fails?

$ git checkout step/3

Slides on transactional application events.

Show added dependencies

Show EventPublicationRegistryTests

Execute EventPublicationRegistryTests

$ git checkout step/4

Additional dependencies added in the POM.

applicationmodules actuator was registered for web exposure in application.properties.

Run the application with the actuator profile enabled (./mvnw spring-boot:run -Pactuator).

Point the browser to http://localhost:8080/actuator. Show how the applicationmodules resource is exposed. Follow the link and show how the JSON exposes the dependency structure in machine readable format.

Show in the logs how the actuators were bootstrapped and the Spring Modulith application module model was bootstrapped asynchronously.