Modular Monoliths & Microservices - A 4+1 View Continuum
Conference (INTERMEDIATE level)
Gallery Hall
Over the last 7 years we used the 4+1 Views to design a system as a modular monolith - saving time, cost and complexity when the team was small & load was low and allowing simpler realignment of module boundaries as we were still discovering the domain. We gradually extracted modules into microservices as needed once we had built confidence in boundaries, when load grew and as the teams expanded and needed autonomy.
How does it work?
The 4+1 views is a way of understanding systems that uses 5 different 'views' of the system, allowing to design and scale different aspects of the system in response to different triggers:
1. The logical view represents functional requirements & scales with domain complexity
2. The process view represents runtime processes & scales with concurrency and deployment requirements
3. The physical view represents the hardware & networks that the processes execute on & scales with load and throughput
4. The development view represents the system as seen by developers (e.g. code) & scales with the number of teams and team size
5. The scenarios view represents the various scenarios in which the system is used & highlights how components in the other views interact
A modular monolith is a system that has 'scaled up' the logical view (multiple modules), but not scaled up the process or physical views (single process, single hardware configuration).
In this talk we'll explore what went well, mistakes we made & tips for adopting this approach.
How does it work?
The 4+1 views is a way of understanding systems that uses 5 different 'views' of the system, allowing to design and scale different aspects of the system in response to different triggers:
1. The logical view represents functional requirements & scales with domain complexity
2. The process view represents runtime processes & scales with concurrency and deployment requirements
3. The physical view represents the hardware & networks that the processes execute on & scales with load and throughput
4. The development view represents the system as seen by developers (e.g. code) & scales with the number of teams and team size
5. The scenarios view represents the various scenarios in which the system is used & highlights how components in the other views interact
A modular monolith is a system that has 'scaled up' the logical view (multiple modules), but not scaled up the process or physical views (single process, single hardware configuration).
In this talk we'll explore what went well, mistakes we made & tips for adopting this approach.
Chris Simon
Chris Simon - Technology Coaching & Advisory
Chris is a technology coach & advisor empowering technology teams to drive business success. He has a particular focus on helping startups realise their vision and new CTOs flourish in their roles. He also supports executives & boards with strategic technology advice, and engineering teams with training, mentoring and consulting in architecture, quality, domain-driven design and test driven development.
He is a regular meetup & conference speaker (NDC, KanDDDinsky, Serverless Days ANZ) and to support teams using Domain-Driven Design, he recently launched https://contextive.tech & co-founded the DDD Australia meetup.
He is the technical co-founder of https://www.inloop.com.au, home of Australian Fintech success stories https://www.flexischools.com.au and https://www.lanternpay.com (recently acquired by NAB).
He is a regular meetup & conference speaker (NDC, KanDDDinsky, Serverless Days ANZ) and to support teams using Domain-Driven Design, he recently launched https://contextive.tech & co-founded the DDD Australia meetup.
He is the technical co-founder of https://www.inloop.com.au, home of Australian Fintech success stories https://www.flexischools.com.au and https://www.lanternpay.com (recently acquired by NAB).