Spring Modulith – A Deep Dive

Slides of the workshop I gave at SpringOne 2023, Las Vegas.

Transcript

1. SPRING MODULITH A DEEP DIVE Oliver Drotbohm odrotbohm@vmware.com odrotbohm
2. Coming in 2023… Follow @mawspring on
3. Introduction
4. Complexity …while the actual challenge is this. Most teams focus on that… 1.0 1.2 1.1 2.0
5. Understandability
6. Changeability
7. Functional Decomposition Encapsulation High Cohesion Low Coupling Modularity
8. A bit of Systems Theory…
9. Systems Thinking, Learning and Problem Solving Long version | Short version Russel L. Ackoff
10. "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."
12. Put things together Pull things apart
13. Pull things apart
14. The System
15. The System Order Product Products Product details Prices Order Line items Customer Details Address Account
16. The System Order Product Products Product details Prices Order Line items Customer Details Address Account Auth PIM Pricing Invoicing Shipment
17. Artifact Process Bounded Context Module Logical Physical Package How do we map this … to that?
18. Monolith VS. Microservice Module A Module B Module C Module B Module C Module A Bounded Context Deployment Unit Internal invocation External invocation
19. Monolith VS. Microservice Module A Module B Module C Bounded Context Deployment Unit Internal invocation External invocation !"
20. Monolith The application packages the implementation of multiple Bounded Contexts as a single deployment unit. Easy to refactor Simple IDE features can be used to move significant parts of the codebase around and update all client code at the same time. Easy to test the overall system An overall test run is a matter of running a Spring (Boot) integration test.
21. Monolith 21 The application packages the implementation of multiple Bounded Contexts as a single deployment unit. Likely to degrade unless explicitly managed Unless explicit means of monitoring the structure are employed, the architecture will degrade over time. Harder to test individual Bounded Contexts Testing individual bounded contexts requires extra effort in setting up Spring configuration to make sure components can be picked up for each module individually.
22. Microservices A bounded context defines the boundaries of the deployment artifact. Often parts of the context are even deployed as separate processes. ◦ Bounded Context interaction is remote The interaction between BCs involved remote interaction, either by sending messages or invoke other systems directly. This accumulates latency, and requires additional measures against the collaborators being unavailable which increases complexity. ◦ Testing individual modules Testing individual modules usually requires collaborating systems to be bootstrapped, stubbed or mocked.
23. Microservices A bounded context defines the boundaries of the deployment artifact. Often parts of the context are even deployed as separate processes. Hard to refactor context boundaries Context boundaries are implemented as published APIs that have to be evolved carefully as clients cannot be updated to server changes immediately. Hard to test the overall system While testing an individual system usually works reasonably well, integration testing multiple systems together is complex and creates additional overhead.
24. Modular Architecture
25. Infrastructure Application Domain
26. Infrastructure Application Domain
27. Onion-/Hexagonal Architecture Modularization
28. Application Domain Infrastructure
29. Application Domain Infrastructure Application Domain Infrastructure
30. Domain Domain Domain Application Infrastructure
31. Application Domain Infrastructure
32. Application Domain Infrastructure
33. Domain Application Infrastructure Domain Application Infrastructure Domain Application Infrastructure
34. Infrastructure Infrastructure Domain Domain Domain Application Application Application Infrastructure
35. Infrastructure Infrastructure Domain Domain Domain Application Application Application Infrastructure
36. Module Module Module
37. The Domain
38. Orders Inventory Order Line items Stock Inventory items
41. Awesome! # Now… what? $
42. How do we represent functional architecture in a codebase? “
43. Let's get started… src/main/java ….acme.myproject ….acme.myproject.domain ….acme.myproject.persistence ….acme.myproject.service ….acme.myproject.web
45. Let's get started… src/main/java ….acme.myproject ….acme.myproject.domain ….acme.myproject.persistence ….acme.myproject.service ….acme.myproject.web %&
46. via https://devopedia.org/cohesion-vs-coupling
47. Domain Based Structure Domain Based Boundaries via Dan North – CUPID—for joyful coding Video cast episode @ Software Architektur im Stream (english)
48. Taking a domain-based approach to the code structure makes it easy to understand what the code is there for, and easy to navigate to wherever you need to be for anything more complicated than “make that button light blue”. Instead, the layout of code—the directory names, the relationships of child and sibling folders, the grouping and naming of related files—should mirror the problem domain as closely as possible. Domain-Based Structure Domain-Based Boundaries “ “ Source: Dan North, CUPID—for joyful coding
49. src/main/java ….acme.myproject ….acme.myproject.customer ….acme.myproject.inventory ….acme.myproject.order Much better… '#
50. via https://devopedia.org/cohesion-vs-coupling
51. Web Business logic Data access @Repository Order Inventory … @Controller @Service Verification? Testing? Documentation? Observation?
53. Sample code odrotbohm/arch-evident-spring events/230821-springone odrotbohm/spring-modulith-deep-dive main
54. Simple Application Modules
55. API Package Convention ….acme ….acme.moduleA ….acme.moduleB Application class goes here Logical modules
56. Some conventions… 01 10 M M 01 10 Allowed by the compiler Allowed by Moduliths Rejected by the compiler Rejected by Moduliths Public Package protected Bounded Context Java Package
57. Module B moduleB Module A moduleA 57 ComponentA ComponentAImpl ComponentB ComponentBImpl Public Package protected Bounded Context Java Package 01 10 01 10
58. package com.acme @SpringBootApplication class MyApplication { … } var modules = ApplicationModules.of(MyApplication.class); modules.verify(…); Applies package conventions Verifies rules for MyApplication
59. Lab time! (#
60. Complex Application Modules
61. Application Domain Infrastructure
62. Infrastructure Application Domain
63. Infrastructure Application Domain Primary (driving) Adapters @Controller @KafkaListener Spring beans Published events Event listeners Secondary (driven) Adapters Repositories Message publishers
64. Infrastructure Application Domain Primary (driving) Adapters @Controller @KafkaListener Spring beans Published events Event listeners Secondary (driven) Adapters Repositories Message publishers
65. API Package Convention 65 ….modulith ….modulith.moduleA ….modulith.moduleA.internal ….modulith.moduleB ….modulith.moduleB.internal Access to components residing in internal packages forbidden and checked during tests. API packages
66. Module A moduleA.foo Module B moduleB moduleA 66 ComponentA ComponentAImpl ComponentB ComponentBImpl moduleA.bar SupportA SupportAImpl 01 10 M 01 10 01 10 Public Package protected Bounded Context Java Package
67. Demo time! (#
68. Integration Testing
69. Web Business logic Data access @Data…Test Module A Module B Module C @WebMvcTest @…Test ?
70. Infrastructure Application Domain Primary (driving) Adapters @Controller @KafkaListener Spring beans Published events Event listeners Secondary (driven) Adapters Repositories Message publishers
71. Infrastructure Application Domain Primary (driving) Adapters @Controller @KafkaListener Spring beans Published events Event listeners Secondary (driven) Adapters Repositories Message publishers
72. Demo time! (#
73. Application Module Integration
74. Pull things apart
75. Put things together Pull things apart
76. Put things together
77. "A system is never the sum of its parts, it's the product of their interactions."
78. Orders Inventory Order Line Items Inventory Item Active invocation Bounded Context Legend Aggregate
79. Orders Inventory Order completed Event Events published to Bounded Context Legend
80. Demo time! (#
81. Error Scenarios Transactional Event Listeners
82. @EventListener @EventListener … @TransactionalEventListener @TransactionalEventListener … @Transactional Event Event Commit Consistency boundary Spring bean Legend
83. Error scenarios
84. What if the service fails? $
85. 84 @EventListener @EventListener … @TransactionalEventListener @TransactionalEventListener … @Transactional Event Event Commit Consistency boundary Spring bean Legend )!
86. 85 @EventListener @EventListener … @TransactionalEventListener @TransactionalEventListener … @Transactional Event Event Commit Consistency boundary Spring bean Legend Rollback! * )!
87. Application events – Error Scenarios The service fails Only standard event listeners up until the failure will have been executed. Assuming the already triggered event listeners also execute transactional logic, the local transaction is rolled back and the system is still in a strongly consistent state. Transactional event listeners are not invoked in the first place.
88. What if an event listener fails? $
89. 88 @EventListener @EventListener … @TransactionalEventListener @TransactionalEventListener … @Transactional Event Event Commit Consistency boundary Spring bean Legend )!
90. 89 @EventListener @EventListener … @TransactionalEventListener @TransactionalEventListener … @Transactional Event Event Commit Consistency boundary Spring bean Legend )! Rollback! *
91. Application events – Error Scenarios A synchronous event listener fails In case a normal event listener fails the entire transaction will roll back. This enables strong consistency between the event producer and the listeners registered but also bears the risk of supporting functionality interfering with the primary one, causing the latter to fail for less important reasons. The tradeoff here could be to move to a transactional event listener and embrace eventual consistency.
92. What if a transactional event listener fails? $
93. @EventListener @EventListener … @TransactionalEventListener @TransactionalEventListener … @Transactional Event Event Commit Consistency boundary Spring bean Legend )!
94. @EventListener @EventListener … @TransactionalEventListener @TransactionalEventListener … @Transactional Event Event Commit Consistency boundary Spring bean Legend Publication lost! " )!
95. Application events – Error Scenarios A transactional event listener fails In case a transactional event lister fails or the application crashes while transactional event listeners are executed, the event is lost and functionality might not have been invoked. Other transactional event listeners will still be triggered. BONUS: An asynchronous event listener fails The event is lost but the primary functionality can still succeed as the event is handled in a separate thread. Retry mechanisms can (should?) be deployed in case some form of recovery is needed.
96. Event Publication Registry
97. @TransactionalEventListener @TransactionalEventListener … Event @TransactionalEventListener … @TransactionalEventListener … Transaction Commit
98. @TransactionalEventListener @TransactionalEventListener … Event @TransactionalEventListener … @TransactionalEventListener … Transaction Commit
99. Demo time! (#
100. Documentation
101. Pace of change Level of detail Effort of manual work
102. Infrastructure Infrastructure Domain Domain Domain Application Application Application Infrastructure
105. Infrastructure Infrastructure Domain Domain Domain Application Application Application Infrastructure
106. Domain Application Infrastructure
107. Infrastructure Application Domain Primary (driving) Adapters @Controller @KafkaListener Spring beans Published events Event listeners Secondary (driven) Adapters Repositories Message publishers
108. My Component Provided Interface Exposed Service API Spring Beans available for DI Exposed Aggregates Primary elements of the domain and constraints Published events Events the component emits Required Interface Consumed Service API External dependencies of Spring beans Configuration Spring Boot configuration properties Consumed events Events that the component reacts to
111. Observability
113. Splitting the Modulith
114. Module Module Module
115. Module Module Module
116. Module Module Module
117. Demo time! (#
118. Summary
119. Spring Modulith A convention to map modules to packages Simple set of access rules and API to verify Test support to bootstrap modules Event publication registry Documentation support Actuator and observability support
120. Spring Modulith Additional implementations of the Event Publication Registry Automatic externalization of events to Kafka, AMQP, potentially Redis
121. Resources Moduliths Project website on GitHub Majestic Modular Monoliths Video on Youtube Modular Monoliths Simon Brown – Video on YouTube Refactoring to a System of Systems Video on YouTube
122. Resources Software Architecture for Developers Simon Brown – Books Just Enough Software Architecture George Fairbanks – Book Architecture, Design, Implementation Ammon H. Eden, Rick Kazman – Paper Sustainable Software Architecture Carola Lilienthal – Book The Programmer's Brain Felienne Hermans – Book
123. Thank you! Questions? Oliver Drotbohm odrotbohm@vmware.com odrotbohm