Architectural Styles I: Monoliths and Modular Designs

Welcome to Chapter 5: Architectural Styles, part one, Monoliths and Modular Designs. Most software, including some of the largest and most successful products, runs as a single deployable application. This chapter explains how such applications should be structured inside, and when a single application is the right answer.

Chapters 3 and 4 gave you the principles of good structure, and the tools for describing it. This chapter and the next turn those principles into the recurring shapes that real systems take. Knowing the main styles lets you start from a shape that is known to work for a given set of qualities, explain it in a sentence, and recognise early when a system is drifting away from it. This chapter covers styles where the whole application is one deployment unit: one build, one release, usually one database. That does not make monoliths primitive. Whether a monolith is a pleasure or a misery to work on depends almost entirely on how it is divided inside.

The chapter is for developers and architects who design or maintain business applications, and want to choose and enforce a structure deliberately. It builds on Chapters 3 and 4, especially modularity, coupling and cohesion, dependencies and layering, and the C4 model. Chapter 2's quality attributes are used throughout. And it leads into Chapter 6, which takes the same questions across a network, where things get harder. A monolith avoids the network failures, partial outages and consistency problems of distributed systems. Chapter 6 takes those on.

First, a definition. An architectural style is a named set of constraints on the kinds of parts a system has, and how they may connect. The constraints are the point. Forbid one business module from touching another's tables, for example, and you get predictable benefits, at a predictable price.

The chapter has eight sections. Section five point one sets up the vocabulary used for every style in Chapters 5 and 6: styles, patterns, tactics and reference architectures. It explains the difference between technical partitioning, by layer, and domain partitioning, by business capability. And it introduces the architecture quantum: an independently deployable part, data included, to which one set of qualities applies.

Here is why partitioning matters. Suppose a food-delivery company lets customers add a tip for the courier. With technical partitioning, that one change touches the presentation layer, the business logic and the persistence layer. With domain partitioning, the same change lands almost entirely in the delivery module, which may still be layered inside. Most business change requests are phrased in domain terms, so domain partitioning tends to keep a change in one place. And it lets each team own a business capability end to end.

Sections five point two to five point five describe four styles in the same format, with a diagram, an example, a table of characteristics, when to use it, and how to enforce it in code. Layered architecture is the familiar stack of presentation, business and persistence layers. The modular monolith divides one deployable application by business domain, with explicit module interfaces and clear data ownership, illustrated by Shopify's experience. Pipes and filters arranges processing as a chain of independent steps, from Unix pipes to data pipelines. And the microkernel builds a minimal core that plug-ins extend, as in development tools, browsers and rules engines.

This diagram from Section five point three shows a modular monolith inside. The dashed boundary is one deployment unit: the food-delivery application. Each module, here Ordering and Payments, has a small public API. Ordering may use Payments only by calling that API. Everything else in a module is internal. Reaching from one module's internals into another's is forbidden. And each module owns its own schema, with no joins across schemas. Keep to these rules, and any module can later be extracted into a service with modest effort.

Section five point six covers hexagonal, onion and clean architecture. They put the business logic at the centre, and make databases, user interfaces and external services depend on it, never the other way round. Section five point seven, on strategic domain-driven design, supplies the method for finding good boundaries: subdomains, bounded contexts, and the relationships between them in a context map. Finally, Section five point eight asks when a monolith is the right answer, how far it can scale, and which signs say it is time to split. It ends with a decision guide and a comparison table for all of the chapter's styles.

If you remember one thing, make it this: the boundaries inside a system matter more than the boundaries between deployment units. A set of services that share a database and call each other's internals is still one tangled system, now with network failures added. Two habits follow. First, choose the simplest style whose characteristics meet the system's architecturally significant requirements, and record the choice and its trade-offs in a decision record. Second, enforce the style's rules with architecture tests in the build, because every style erodes when its constraints live only in people's heads.

Read Section five point one first, because every later section uses its vocabulary. After that, you can take the styles in order or dip into the one you need. The chapter takes about three hours to read. Follow the food-delivery platform as it runs through the chapter. Comparing the styles on one familiar system is far easier than on unrelated toy examples. Each section ends with a few self-check questions. Answer them in your head before you look. When you are ready, take the optional chapter test: twenty multiple-choice questions and two written answers, in about forty five minutes. The pass mark is eighty per cent.

That is the map of Chapter 5. Start with Section five point one, where we set up the vocabulary of styles, patterns and tactics that the next two chapters rely on. See you there.