The Way of the Modular Monolith, Victor Rentea

The Way of the Modular Monolith, with Victor Rentea, at Codecamp_Festival 2023
The microservices honeymoon is over - a team is merging nano-services back into a more manageable solution. Meanwhile, a larger team is adding one more feature to their legacy monolith aka macro-service, trying to find ways to break down its complexity. What both teams need is to learn how to progressively transition a monolithical codebase into decoupled modules in tiny baby steps, reflecting on the selected boundaries and enforcing them along the way.
This talk will walk you through the key steps to move towards a Modular Monolith, aka Modulith. You will hear about Bounded Contexts, breaking data structures, internal/external module APIs, choreography vs orchestration, events, transactions, and 6 ways to fix cyclic dependencies between modules.
Finally, extracting such a module into a microservice becomes a trivial task. But, like some of Victor's clients, you may be so happy with your codebase that you would choose NOT to take that dangerous step towards microservices.
codecamp.ro/codecamp_festival...

[@prantodas9397]

Great delivery ♥

[@MbgChat]

This is pure gold. Great delivery as well.

[@quaesitor-scientiae]

🎯 Key Takeaways for quick navigation:
00:44 *🌐 Monoliths, while common, often suffer from tangled code, patches, and slow adaptation, making them risky to change.*
03:58 *💡 Large projects can suffer more from internal domain coupling than from external dependencies like libraries or frameworks.*
04:40 *🚀 Microservices offer faster time to market, scalability, fault tolerance, and technology flexibility, but come with a high operational cost.*
06:58 *🔧 Big-bang rewrites of monoliths into microservices often lead to disappointing results, risking a transition to a distributed monolith.*
10:55 *🎯 Modular monoliths serve as a transition from legacy monoliths to microservices, allowing gradual modularization and potential extraction into microservices.*
14:13 *💼 Teams working on modules in a modular monolith can function independently, fostering productivity and collaboration.*
16:29 *🛠️ Grouping modules by business capabilities rather than data enhances modularity and independence.*
22:52 *📚 Domain-Driven Design emphasizes bounded contexts, advocating for smaller, more tailored domain models within modules.*
24:50 *🏗️ Modular Monolith vs Microservices: Uber's journey from microservices back to a more manageable solution highlights the pitfalls of overly fragmented architecture.*
26:21 *🤝 Coupling vs Cohesion: Striking a balance between breaking down modules for high cohesion and avoiding excessive coupling is crucial in architectural design.*
27:16 *🧩 Evolutionary Architecture: Embrace simplicity initially and evolve the design gradually as complexity grows, focusing on responsibilities and delineating modules.*
28:26 *🧪 Techniques for Module Communication: Utilize compiler checks and unit tests to enforce module boundaries and prevent unwanted dependencies.*
30:28 *📡 Module Communication Methods: Modules communicate through calls, events, and public APIs, akin to microservices, but with simpler design principles.*
35:33 *🔄 Addressing Cycle Dependencies: Six methods to fix cycle dependencies include extracting API modules, using events, shared modules, entry points, merging modules, and employing polymorphism.*
42:46 *📡 Module Surface: A module's surface includes calls, events, and exposed interfaces, defining its interactions with other modules.*
43:28 *💾 Data Management in Modules: Modules should be responsible for their own data, with careful consideration for access, isolation, and consistency.*
45:20 *🧪 Testing Considerations: Testing a modular monolith is easier and cheaper compared to testing multiple microservices, with integration tests spanning single modules.*
46:54 *🛠️ Choosing Modular Monoliths: Opt for modular monoliths when migrating from legacy systems, starting Greenfield projects, or for systems not requiring frequent changes or extreme scalability.*
Made with HARPA AI

[@prantodas9397]

Audio 😥

[@rommellagera8543]

Why on earth monolith system equals bad system. I've been developing monolith for almost 30 years. One, Rural Telco billing system, has been developed, enhanced and maintained for more than 2 decades. My only problem is power in rural areas (UPS conk out).
If you cannot do decent monolith with it's easier implementation, how can you do microservices which is far more complex than most will admit.

[@themadpixel]

depends on the size of the monolith