Modulith Instead of Monolith - Pragmatically Towards Microservices
-
Hendrik Lösch
Migration, Software Evolution, Architectur, QA, Test Automation, TDD, Clean Code
The basic premise is that by making our service landscape more modular we increase innovation speed at the company level.
Different factors while taking that decision. Coupling, Cohesion, Encapsulation. Lets make trade-offs between them when making design decisions.
Lets take a real problem and design a system and measure its modularity. Pure maths can help us making faster decisions, hence increase innovation.
Unfortunate: We use the term microservices nano services / functions | lambdas it’s not about the size of the boat, but about the motion in the ocean. Smaller is not (perse) better Reflect on cost vs benefit
So how can we design better? What is modulith? Perfect marriage of a monolith and boundaries of a microservice is clearly a golden bullet.
Results: system ~ bounded context system != deployable system >= 1 deployable strong cohesive deployables loosly coupled deployables belong together exposed under a single api isolation by system
World Congress 2024
Hendrik Lösch
Migration, Software Evolution, Architectur, QA, Test Automation, TDD, Clean Code
Eberhard Wolff
Head of Architecture, SWAGLab
Loïc Carbonne
Head of ecommerce division at Theodo
Florian Lenz
neocentric GmbH - Azure Serverless Developer / Architect