Building Moduliths That Last: Patterns for Sustainable Module Integration

A system does not need to be distributed to have clean architectural boundaries. Moduliths (modular monoliths) have emerged as a popular alternative to microservices - But doesn't that mean we're going back to where we started from? Won't today's moduliths end up as Big Balls of Mud again in a few years?

The key to a sustainable modulith is clean integration between modules. The shared runtime offers more integration options but also creates the temptation to take shortcuts and create a hot mess. This talk compares different approaches to integrating modules in a modulith. We will explore how different domains suit specific patterns better than others, and distill that knowledge into practical heuristics. We will also examine tactics for establishing these patterns in existing codebases.

As a developer or architect, you will leave with a toolkit of modulith integration patterns and antipatterns, guidelines for choosing the right ones, and the knowledge to establish them in legacy applications.

Transcript

1. Building Moduliths That Last Patterns for Sustainable Module Integration
2. We overdid it with microservices ! True! In most cases , a modulith would be enough ! I agree …
3. If it’s so easy to create a well - structured modulith … Why are most real - life monoliths BIG BALLS OF MUD?
4. LEAD SOFTWARE ENGINEER Christoph Kober If it’s so easy to create a well - structured modulith … Why are most real - life monoliths BIG BALLS OF MUD? Transformation Engineer Fan of Japan DDD Aficionado
5. EXAMPLE Internet Banking Solution
6. Without a modularized database your application is not modular!
7. The problem is not the technology it’s a lack of separation of concerns –
8. WELCOME TO City Tour Now
9. WELCOME TO City Tour Now
10. OUR EXAMPLE DOMAIN CityTour.now CityTour.now Deployment Monolith Guides Tours Payments Guides DB Tours DB Payments DB
11. As we dive into the existing codebase , we find that all modules are integrated with direct calls . Is that a problem ? How can we improve the situation ?
12. INTEGRATION PATTERNS Direct Calls @Transactional public void cancelTour(CancelTourCommand command) { var now = LocalDateTime.now(); var tour = tourRepository.findRequiredById(command.tourId()); tour.cancel(now); } var paymentPool = paymentService.getPaymentPool(tour.getId().toString()); paymentPool.refund(now);
13. INTEGRATION PATTERNS The Good Parts Direct Calls - USAGE – The Bad Parts Starting Point Tight Coupling Simple Applications Leaking Internals Moving away from DB Integration Implicit Interfaces
14. INTEGRATION PATTERNS Direct Calls @Transactional public void cancelTour(CancelTourCommand command) { var now = LocalDateTime.now(); var tour = tourRepository.findRequiredById(command.tourId()); tour.cancel(now); } var paymentPool = paymentService.getPaymentPool(tour.getId().toString()); paymentPool.refund(now);
15. INTEGRATION PATTERNS - REFACTORINGS Refactoring – Introduce Facade @Transactional public void cancelTour(CancelTourCommand command) { var now = LocalDateTime.now(); var tour = tourRepository.findRequiredById(command.tourId()); tour.cancel(now); payments.refund(new RefundPaymentPoolCommand(tour.getId().toString())); var paymentPool = paymentService.getPaymentPool(tour.getId().toString()); } paymentPool.refund(now); }
16. INTEGRATION PATTERNS - REFACTORINGS Refactoring – Introduce Mediator @Transactional public void cancelTour(CancelTourCommand command) { var now = LocalDateTime.now(); var tour = tourRepository.findRequiredById(command.tourId()); tour.cancel(now); mediator.send(new payments.refund(new RefundPaymentPoolCommand(tour.getId().toString())); var paymentPool = RefundPaymentPoolCommand(tour.getId().toString())); paymentService.getPaymentPool(tour.getId().toString()); } paymentPool.refund(now); }
17. MEDIATOR Decoupling using Mediator Tours refundPaymentPool Payments
18. MEDIATOR Decoupling using Mediator Tours RefundPayment PoolCommand refundPaymentPool Mediator RefundPayment PoolCommand Payments
19. MEDIATOR Replaceability Tours RefundPayment PoolCommand Mediator RefundPayment PoolCommand External Payment System
20. MEDIATOR Replaceability Tours Tours refundPaymentPool RefundPayment PoolCommand Mediator Payments RefundPayment PoolCommand External Payment System
21. Direct Calls introduce explicit contract Facade decouple with Mediator
22. All integrations now live directly in the modules . It’s hard to follow a full business workflow end - to - end. What can we do?
23. INTEGRATION PATTERNS Orchestration Layer @Component public class CancelTourWorkflow { // ... } @Transactional public void cancelTour(UUID tourId) { tours.cancelTour(new CancelTourCommand(tourId)); payments.refund(new RefundPaymentPoolCommand(tourId.toString())); }
24. INTEGRATION PATTERNS Orchestration Layer CityTour.now Deployment Monolith Orchestration Layer Guides Tours Payments
25. INTEGRATION PATTERNS Refactoring – Introduce Orchestration Layer @Component public class CancelTourWorkflow { // ... @Transactional public void cancelTour(UUID tourId) { tours.cancelTour(new CancelTourCommand(tourId)); } payments.refund(new RefundPaymentPoolCommand(tourId.toString())); } } }
26. INTEGRATION PATTERNS Refactoring – Introduce Orchestration Layer @Component public class CancelTourWorkflow { // ... } @Transactional public void cancelTour(UUID tourId) { tours.cancelTour(new CancelTourCommand(tourId)); payments.refund(new RefundPaymentPoolCommand(tourId.toString())); }
27. INTEGRATION PATTERNS The Bad Parts Business Logic creeping in - USAGE Orchestration Layer – The Good Parts Valuable for a transition phase Full decoupling of Modules Anemic Models & Modules Full process in one place Easy to implement Hard to distribute later Full process in one place
28. Direct Calls introduce explicit contract Facade use as foundatio n for Orchestration Layer decouple with Mediator replace with
29. Our orchestration layer grew . It mostly solves integration problems ; the business workflows became secondary . Do we have alternative options ?
30. INTEGRATION PATTERNS Process Engines
31. INTEGRATION PATTERNS - USAGE Process Engines The Bad Parts Business Logic creeping in – The Good Parts Adaptable by Business Experts Visualized Process Anemic Models & Modules Supports media discontinuity Rarely touched by non - coders Live Process Observability Code is easier to work with Reusability & Customization
32. Direct Calls introduce explicit contract Facade use as foundatio n for Orchestration Layer decouple with Mediator replace with replace with Process Engine
33. We want to continuously extend our workflows . But as we are going , more and more details are creeping in and coupling increases . How can we improve the evolvability of our workflows ?
34. INTEGRATION PATTERNS INTEGRATION PATTERNS Events – Publishing Events – Processing @Transactional public void cancelTour( CancelTourCommand command) { @EventListener @Transactional public void onTourCancelled( TourCancelledEvent event) { var tour = tourRepository .findRequiredById(command.tourId()); var pool = paymentPoolRepository .findByReference(event.tourId().toString()); tour.cancel(LocalDateTime.now()); } publisher.publish( new TourCancelledEvent(tour.getId())); } pool.refund(LocalDateTime.now());
35. EVENTS Decoupling and Inverting Dependencies Tours Tour CancelledEvent Event System Payments
36. EVENTS Evolvability Payments Tours Tour CancelledEvent Event System Notifications
37. INTEGRATION PATTERNS Events - USAGE – The Bad Parts Need to be versioned Asynchronous by default Eventual consistency
38. INTEGRATION PATTERNS Events - USAGE – The Bad Parts Need to be versioned Asynchronous by default Eventual consistency Does not automatically apply to moduliths !
39. INTEGRATION PATTERNS The Good Parts Events - USAGE – The Bad Parts Pipeline Domains Process is code - only & implicit Complex integrations Observability is harder Evolvability needed Requires rethinking
40. You don’t need Event Sourcing to use events for integration!
41. If you are using Event Sourcing, separate between your Event Sourcing events and your Integration events
42. Direct Calls introduce explicit contract Facade introduc e Events split workflow with use as foundatio n for Orchestration Layer decouple with Mediator Integration Events replace with replace with Process Engine
43. Through events , we can integrate our change workflows and make them extendable . But sometimes , we just want to view data from different modules in the same UI. Do we really need to integrate all data through events to achieve this ?
44. INTEGRATION PATTERNS UI Integration
45. INTEGRATION PATTERNS UI Integration GUIDES MODULE UI GUIDES MODULE BUSINESS LOGIC Guides DB
46. OUR EXAMPLE DOMAIN UI Integration – Towards Self - Contained Systems CityTour.now Deployment Monolith Guides Tours Payments Guides DB Tours DB Payments DB
47. OUR EXAMPLE DOMAIN UI Integration – Towards Self - Contained Systems CityTour.now Deployment Monolith GUIDES MODULE TOURS MODULE UI PAYMENT MODULE UI UI Guides Tours Payments BUSINESS LOGIC BUSINESS LOGIC BUSINESS LOGIC Guides DB async Tours DB async Payments DB
48. INTEGRATION PATTERNS The Bad Parts Business Logic creeping in - USAGE UI Integration – The Good Parts Backoffice Use - Cases Transition Phase Nano - Frontend Trap Dashboards Only for User Interactions Diversified Businesses
49. Direct Calls introduce explicit contract replace read - only data integration Facade decouple with introduc e Events split workflow with use as foundatio n for Orchestration Layer replace read - only data integration UI Integration Mediator Integration Events replace with replace with Process Engine
50. What are our takeaways ?
51. The Highlander Principle does not apply It’s all about explicit contracts Let your domain guide the way
52. Feeback is a gift Download the Slides
53. Enabling teams. Transforming IT landscapes. Digitalizing enterprises. Althanstraße 4/3/63 1090 Vienna (+43) 676 849963 200 August - Everding - Str. 25 81671 Munich (+49) 151 5251 7885 office@squer.io www.squer.io www.code - crafts.com