It Takes Two to Tango – Designing Module Interactions in Modulithic Spring Applications

According to Russell Ackoff “A system is not the sum of the behaviors of its parts, but the product of their interactions”. That’s why the design of those interactions is of the uttermost importance. In a Spring application, the primary means to establish relationships between application components is dependency injection (DI). With higher-level structuring approaches like Spring Modulith’s application modules in place, should the interaction of those be implemented by DI as well?

The talk presents different approaches to designing application module interactions and compares them regarding their applicability, effect on testability, consistency, error scenarios and how they affect the modularity of the system overall.

Transcript

1. IT TAKES TWO TO TANGO DESIGNING MODULE INTERACTIONS IN MODULITHIC SPRING APPLICATIONS Oliver Drotbohm oliver.drotbohm@broadcom.com odrotbohm
4. Systems Thinking, Learning and Problem Solving Long version | Short version Russel L. Ackoff
5. "A system is a whole that consists of parts, each of which can affect its behavior and properties. … Each part of the system is dependent on some other part."
6. A B
7. A B ! Risk of Change Risk of Error
8. "A system is never the sum of its parts, it's the product of their interactions."
9. How do we establish code interaction in a Spring application?
10. Controller Service Repository Layered Hexagonal Onion Presentation → Business → Persistence Driving Adapter → ← Driven Adapter Port ← Application → Port Infrastructure → ← Infrastructure Application / Domain Spring DI DI
11. Technical Decomposition Functional Decomposition VS.
12. Checkout Inventory Rewards Program Notifications Primary Secondary Submit order Update stock Calculate bonus points Send confirmation email
13. Checkout Inventory Rewards Program Notifications Primary Integration via DI Secondary
14. @Service @RequiredArgsConstructor class Checkout { private final OrderRepository orders; @Transactional void complete(Order order) { orders.save(order.complete()); } } Primary State transition Internal, technical decomposition
15. @Service @RequiredArgsConstructor class Checkout { private final OrderRepository orders; private final Inventory inventory; private final RewardsProgram rewards; private final Notifications notifications; @Transactional void complete(Order order) { orders.save(order.complete()); inventory.updateStock(…); rewards.registerRewards(…); notifications.sendOrderConfirmation(…); } } @Service class Inventory { } @Service class RewardsProgram { } @Service class Notifications { } Secondary Required at startup / in tests Primary Interaction expands transaction
16. Checkout Inventory Rewards Program Notifications Primary @Transactional Scope of Consistency Secondary
17. @SpringBootTest class CheckoutTests { @Autowired Checkout checkout; @MockBean Inventory inventory; /" Other mocks @Test void completesOrder() { var order = new Order(…); checkout.complete(order); verify(inventory).updateStock(…); } } Collaborator are mocked Given / When / Then Testing focussed on orchestration
18. Checkout Inventory Rewards Program Notifications Primary @Transactional Integration via Events Secondary
19. @Service @RequiredArgsConstructor class Checkout { private final OrderRepository orders; private final ApplicationEventPublisher events; @Transactional void complete(Order order) { orders.save(order.complete()); events.publishEvent( OrderCompleted.of(order.getId())); } } @Service class Inventory { @EventListener void on(OrderCompleted event) {} } … Primary Secondary Invokes Only internal dependencies
20. @RecordApplicationEvents /# or *% @ApplicationModuleTest class CheckoutTests { private final Checkout checkout; @Test void completesOrder(AssertableApplicationEvents events) { var order = new Order(…); checkout.complete(order); assertThat(events) .contains(OrderCompleted.class) .matching(OrderCompleted:#id, order.getId()); } } Given / When / Then Spring Modulith Records events published during test execution Spring Framework Testing focussed on signal
21. Checkout Inventory Rewards Program Notifications Primary @Transactional Integration via Events Secondary
22. Checkout Inventory Rewards Program Notifications Primary @Transactional Invocation Flow for Events Secondary
23. Summary Change in structural arrangement Change in approach to testing No change to consistency arrangement
24. Checkout Notifications Inventory Rewards Program Primary Secondary @Transactional Database SMTP
25. Checkout Notifications Inventory Rewards Program Primary Secondary @Transactional Database SMTP Resource management? Consistency?
26. @Service @RequiredArgsConstructor class Checkout { private final OrderRepository orders; private final ApplicationEventPublisher events; @Transactional void complete(Order order) { orders.save(order.complete()); events.publishEvent( OrderCompleted.of(order.getId())); } } @Service class Notifications { @EventListener void on(OrderCompleted event) { /" Interact with SMTP server } } Primary Secondary What if this takes long?
27. @Service @RequiredArgsConstructor class Checkout { private final OrderRepository orders; private final ApplicationEventPublisher events; @Transactional void complete(Order order) { orders.save(order.complete()); events.publishEvent( OrderCompleted.of(order.getId())); } } @Service class Notifications { @EventListener void on(OrderCompleted event) { /" Interact with SMTP server } } Primary Secondary What if this succeeds but this rolls back?
28. Original business transaction Begin Commit / End @EventListener Time Checkout Inventory
29. Checkout Notifications Inventory Rewards Program Primary Secondary @Transactional Database SMTP
30. Inventory Rewards Program Notifications @Transactional Checkout Primary Secondary Database SMTP
31. @Service @RequiredArgsConstructor class Checkout { private final OrderRepository orders; private final ApplicationEventPublisher events; @Transactional void complete(Order order) { orders.save(order.complete()); events.publishEvent( OrderCompleted.of(order.getId())); } } @Service class Notifications { @TransactionalEventListener void on(OrderCompleted event) { /" Interact with SMTP server } } Primary Secondary Triggered on transaction commit
32. Original business transaction Begin Commit End @TransactionalEventListener Time Checkout Notifications
33. @Service @RequiredArgsConstructor class Checkout { private final OrderRepository orders; private final ApplicationEventPublisher events; @Transactional void complete(Order order) { orders.save(order.complete()); events.publishEvent( OrderCompleted.of(order.getId())); } } @Service class Notifications { @Async @TransactionalEventListener void on(OrderCompleted event) { /" Interact with SMTP server } }
34. Original business transaction @Async @TransactionalEventListener Begin Time Checkout Notifications Commit / End
35. What if a transactional event listener fails? "
36. @TransactionalEventListener @TransactionalEventListener … @TransactionalEventListener … @TransactionalEventListener … Transaction Commit
37. @Service @RequiredArgsConstructor class Checkout { private final OrderRepository orders; private final ApplicationEventPublisher events; @Transactional void complete(Order order) { orders.save(order.complete()); events.publishEvent( OrderCompleted.of(order.getId())); } } @Service class Inventory { @ApplicationModuleListener void on(OrderCompleted event) { /" Interact with SMTP server } }
38. @ApplicationModuleTest class CheckoutTests { private final Checkout checkout; @Test void completesOrder(Scenario scenario) { var order = new Order(…); scenario.stimulate(() -% checkout.complete(order)) .andWaitForEventOfType(InventoryUpdated.class) .matchingMappedValue(InventoryUpdated:#getOrderId, order.getId()) .toArrive(); } } Spring Modulith Given / When / Then
39. Summary Functional decomposition first, technical decomposition second Align consistency scope and testing with functional boundaries In modulithic arrangements, use spectrum of integration options and consistency levels Spring Modulith for advanced support
40. Classic Event Listener Application Module Listener Module references via Spring beans via @EventListener via @ApplicationModuleListener (@Async @TransactionalEventListener) Integration style synchronous synchronous Asynchronous / Transaction-bound Tests Orientation vertical / horizontal vertical vertical Focus Module interaction Module operation outcome signaled by an event Module operation outcome signaled by an event Approach via mocks / @MockBean via AssertablePublishedEvents via Scenario Risk Integration tests including multiple modules Tests exclude code that could break transaction at runtime Asynchronous module interaction Consistency Boundaries Potentially (accidentally) spanning multiple modules Potentially (accidentally) spanning multiple modules Aligned with module boundaries / Eventual Consistency / Mechanism Transaction Transaction Event Publication Registry Module coupling
41. Thank you! Questions? Sample Code Oliver Drotbohm oliver.drotbohm@broadcom.com odrotbohm