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.

So 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 functional complexity
2. The process view represents executable processes & how they interact & 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.