Module 6: Designing for Change
Module introduction: designing for change
Why this module exists here
Almost everything said about software architecture hides a verb in the past tense. "The system is designed this way", "the architecture is microservices", "we decided to use a database per service". It sounds like a photograph: a fixed state someone captured and that stays there. And that grammar is a trap, because a living system isn't a photograph —it's a film—. It changes every day: features come in, volumes grow, the business pivots, requirements appear that no one imagined the day the first diagram was drawn. The question almost no one asks, and that this module puts at the center, isn't "what's the right architecture?" but "is this architecture postured to change when the business asks for it, or is it going to fight against every change until rewriting it is the only way out?".
This whole guide teaches the human and organizational craft of being an architect. In module 1 you dismantled the myth of the role —the architect doesn't produce diagrams, they produce conditions—. In module 2 you saw how the organization shapes the system (Conway). In module 3 you learned to communicate with C4 and the ADR. In module 4, to lead without authority. In module 5, to translate business goals into quality attributes. All those modules rested on an assumption they never said out loud: that once you decide well, the thing stays still. This module brings that assumption to light and dismantles it. No architecture is final. The architect's work doesn't end when the design is approved; that's barely where the long part begins: accompanying the system's evolution through years of changes that weren't in the blueprint.
And here we must be precise about the ecosystem's frontier, because it's delicate. The sister guide architecture-decisions-and-tradeoffs teaches the mechanics of deciding under change: how to classify a decision as a one-way or two-way door, how to compute the last responsible moment, how to measure and pay technical debt. That's technique, and we don't re-teach it here. This module teaches the mental stance of the architect who embodies that technique: the inner disposition of one who plans for change and not for permanence, who keeps options open as a craft, who builds knowingly things they'll throw away, and who walks between over-engineering and under-engineering without falling into either. The technique is the other guide's; the professional identity that uses it is this one's. When in this module we talk about "leaving a seam", we won't re-teach how to classify a one-way door —that's the other guide—; we'll teach why an architect who designs for change leaves that seam by stance, not by accident.
The case, seen over time: Mercado and its monolith that will be services
Mercado is the marketplace that accompanies us throughout the guide, and here we look at it through a different lens: time. Recall its organization —five squads: catalog, orders, payments, shipping, platform—. And recall its system, which in module 2 we diagnosed as a monolith: a single large deployment, with a shared database, born when Mercado was a small team and a simple product.
Mercado's architect knows something that doesn't appear in any current diagram: that today's monolith will be services tomorrow. They don't know it because the monolith is bad —for today's Mercado, with its size and its traffic, the monolith is probably the right decision; splitting it now would be over-engineering—. They know it because the business is going to grow, it's going to press the seams, and the moment will come when a piece of the monolith —the catalog, the payments, the shipping— will need to live apart to scale, to deploy on its own, to have a team own it whole. That moment will come. The architect's question isn't whether it will come, but: when it comes, will the monolith be postured to let that service out without pain, or will half the system have to be rewritten?
There's the craft of this module, and it's a fine balance:
- If the architect, fearful of the future, rewrites the monolith into microservices today —when the business isn't asking for it yet—, they commit over-engineering: they pay the complexity of a distributed system (networks, latency, eventual consistency, five deployments) for a problem they don't have yet. They built flexibility for a future that might take years, or never come.
- If the architect, out of misunderstood simplicity, welds the monolith into a ball with no internal boundaries —everything calls everything, the database is a shared tangle, there isn't a single seam—, they commit under-engineering: when the business asks to split off the catalog, there'll be no line to cut along, and the extraction will cost a fortune in rewriting. They painted themselves into a corner.
- The architect who designs for change does the third thing: they keep the monolith —simple, one deployment— but leave the seams in place. Within the monolith, the catalog talks to the orders through a clear interface, not by getting its hands into their tables; the modules have internal boundaries even though they share a process; there's a contract where tomorrow there'll be a network. The day the business asks for the catalog service apart, the seam is already there: it's cut along the dotted line, not rewritten.
That third architect is the module's protagonist. They don't guess the future; they posture the system to receive it. And they do it by measuring, not by hunch.
Connection with the module. This is the map lesson. It doesn't go deep into any of the seven pieces; it installs the thesis (no architecture is final; it's a flow of decisions, and the craft is designing the seams between two abysses), the vocabulary (optionality, sacrificial architecture, YAGNI, over-engineering, under-engineering, seam, right-sizing), and the map of how each lesson builds the stance. Lesson 2 installs that the architecture is a flow, not a frozen artifact. Lesson 3 teaches optionality: keeping doors open under uncertainty. Lesson 4, sacrificial architecture: building to throw away. Lesson 5 marks the first abyss, over-engineering (YAGNI). Lesson 6, the second, under-engineering (painting into a corner). Lesson 7 synthesizes: designing the seams at the sensible point. And lesson 8 puts you to designing Mercado's evolution for a real change, executed. Watch the frontier: reversibility and the last responsible moment as a technique are the sister guide architecture-decisions (its module 7); here we work the stance of the one who embodies it.
And the usual promise: even though the subject is a mental stance, what's quantifiable is executed, not asserted. Every simulation runs with Python 3.14 and the standard library only, with fixed data, so the output of each "What to expect" block is the literal output of running the code. You can copy it and reproduce it identically.
An analogy: the urban planner who reserves the land for the avenue that doesn't exist yet
Think about how a city is planned, and two urban planners in front of the same empty lot on the outskirts.
The first planner designs for the present and only for the present. Today there's a small town, so they lay out narrow streets, pack the houses to the edge of each lot, and use every available square meter —"why leave empty space if there's no traffic?"—. It's efficient, it looks full and used. Ten years later the town is a city, the traffic collapses, and a big avenue is needed to cross the area. But there's nowhere for it: the houses are stuck to each other, every meter is built. Opening the avenue now means expropriating and demolishing hundreds of houses, at a brutal political and economic cost. The planner optimized for the present and painted the city into a corner.
The second planner commits the opposite error. Terrified of the future, they pave from day one a twelve-lane avenue, with interchanges, bridges, and an airport —for a town of three thousand inhabitants—. All that costs a fortune, half of it cracks unused because there's no traffic to justify it, and the maintenance of oversized infrastructure eats the town's budget for decades. They built for an imagined future that maybe never comes —or comes so late that the infrastructure is already obsolete—. Urban over-engineering.
The third planner —the good one— does something much subtler. They don't build the avenue. But they reserve the right-of-way: they leave a strip of land unbuilt along which, the day the traffic asks for it, the avenue can be opened without demolishing anything. They don't pave twelve lanes today; they leave the space to pave them tomorrow, cheaply. The reserved strip barely costs anything —it's land not sold for houses—, but it changes the future completely: when the city grows, the avenue opens along the strip that was always there, without expropriations or demolitions. The planner didn't guess when the traffic would come nor how many lanes would be needed; they postured the city to receive the avenue when it was necessary.
That reserved strip is the seam of this module. The architect who designs for change doesn't build the future in advance (over-engineering, the second planner) nor paint themselves into a corner by building everything to the edge (under-engineering, the first). They leave the seams —the right-of-way— where the probable change is going to pass: the clear interface between catalog and orders, the contract where tomorrow there'll be a network, the abstraction that lets the payments provider be swapped. Cheap today, decisive tomorrow. And the mastery, just as in the city, is in knowing where to reserve land (for the avenue that will probably come) and where not (for the airport that almost surely won't). This module trains that mastery, and puts it in numbers.
Worked example: the half-life of the day-one design
Let's start with the hardest evidence for the thesis: no architecture is final. It's not a philosophical opinion; it's measurable. A design doesn't become obsolete all at once the day it "fails"; it erodes slowly, assumption by assumption, as the business invalidates the premises it was drawn on. We're going to measure how much of Mercado's day-one design remains standing as the years pass.
We take eight assumptions of Mercado's initial architecture —things the day-one design took as true—. Each has an annual probability of being invalidated by a business change: Mercado opening a second country invalidates single_region and english_only; growing payment volume invalidates one_payments_provider; the checkout not being allowed to go down invalidates synchronous_orders_to_shipping; and so on. It's not that they'll die for sure; it's that each year they run a certain risk of the business knocking them down. We measure how many of the original design's assumptions are expected to remain alive year after year:
# No architecture is final. The assumptions of the day-1 design don't die
# all at once: the business invalidates them one by one over time. Each assumption
# of Mercado's initial architecture has an ANNUAL probability of being
# invalidated by a business change. We measure what fraction of the original design
# remains standing year after year.
ASSUMPTIONS = [
# (day_1_assumption, prob_invalidated_per_year)
("single_shared_database", 0.25),
("one_payments_provider", 0.30),
("synchronous_orders_to_shipping", 0.20),
("monolith_deploy", 0.35),
("single_region", 0.15),
("no_external_api", 0.30),
("english_only", 0.20),
("session_in_memory", 0.25),
]
total = len(ASSUMPTIONS)
print(f"{'year':>4}{'assumptions alive (expected)':>32}{'% of day-1 design':>22}")
print("-" * 58)
for year in range(0, 6):
alive = sum((1 - p) ** year for _, p in ASSUMPTIONS)
print(f"{year:>4}{alive:>32.2f}{alive / total * 100:>21.1f}%")
print("-" * 58)
survive5 = sum((1 - p) ** 5 for _, p in ASSUMPTIONS)
print(f"Of {total} day-1 assumptions, by year 5 ~{survive5:.1f} survive")
print(f"({survive5 / total * 100:.0f}% of the original design). Around year 2-3 HALF")
print("was already invalidated. The 'definitive design' doesn't exist: it's a flow of decisions.")What to expect. Running the file, the output is exactly this:
year assumptions alive (expected) % of day-1 design
----------------------------------------------------------
0 8.00 100.0%
1 6.00 75.0%
2 4.53 56.6%
3 3.44 43.0%
4 2.63 32.9%
5 2.03 25.3%
----------------------------------------------------------
Of 8 day-1 assumptions, by year 5 ~2.0 survive
(25% of the original design). Around year 2-3 HALF
was already invalidated. The 'definitive design' doesn't exist: it's a flow of decisions.
Read the percentage column slowly, because it's the whole module's argument in one table.
On day zero, 100% of the design is in force —of course, it was just drawn—. By year 1, 25% of the assumptions is already expected to have fallen: only 75% survives. By year 2 you're at 56.6%, and between year 2 and 3 the design crosses the half mark: more than half the premises the original architecture was drawn on no longer apply. By year 5, barely 25% of the day-one design is still standing. Three quarters of the assumptions Mercado was built on were invalidated by the business in five years —not because of bad design, but because the world moved—.
This is the half-life of an architecture, and it has a devastating consequence for the idea of the "definitive design". If in five years 75% of your premises are going to change, then chasing the perfect diagram that holds forever is chasing a ghost: 75% of that perfect diagram is going to be wrong in five years, no matter how well you draw it today, because you can't draw against a world that hasn't happened yet. The perfect and permanent design doesn't exist. What exists is a flow of decisions: an architecture that receives a new decision every time an assumption falls, and that is —or isn't— postured to receive it cheaply.
Notice the mindset shift this forces. The photograph architect asks: "what's the right design?" —and tries to get it right in one go—. The film architect asks something else: "when this assumption falls —and it will— will my architecture be able to absorb the change, or will it fight against it?". The first question chases an impossible permanence; the second designs for the only sure thing, which is change. The whole module develops the second question: how to keep options open (lesson 3), when to build to throw away (lesson 4), and —the heart— where to put the seams without falling into over-engineering (lesson 5) or under-engineering (lesson 6), at the sensible point lesson 7 measures.
An honest nuance before continuing: that 75% of the assumptions change in five years does not mean everything has to be redesigned every year, nor that planning is useless. It means the opposite: since you know the design is going to erode, you plan for eroding to be cheap —leaving seams— instead of planning a design that pretends it won't erode. The lesson isn't "don't design"; it's "design for the flow, not for the photo".
The six pieces of the stance
That example touched, without developing it, the module's thesis. Each lesson installs a piece of the stance of the architect who designs for change. It's worth seeing them together, because they're the backbone of the seven lessons that follow.
1. The architecture is a flow, not a photo (lesson 2). The first piece: stop thinking of the architecture as an artifact that freezes and start thinking of it as a flow of decisions that runs the whole life of the system. We measure the accumulated cost of the "frozen" stance against the "fluid" one: it's not one change that breaks it, it's the accumulation.
2. Keeping the doors open —optionality (lesson 3). Under uncertainty, an open option has value even if you never exercise it, like insurance. But it costs a premium. The lesson measures when the premium is worth it (when the change is fairly probable) and when it's wasted (when it isn't) —the break-even point—.
3. Building to throw away —sacrificial architecture (lesson 4). Sometimes the best way to reduce uncertainty is to knowingly build something disposable: a prototype that validates and gets replaced. It's not waste; it's the scaffold that's paid for to raise the building well. The lesson measures when the prototype comes out cheaper than building "in one go".
4. The first abyss: over-engineering —YAGNI (lesson 5). Building flexibility "just in case" for imagined futures that almost never come. The lesson measures the waste: paying for the flexibility of all futures against paying the rework only of the ones that arrive —an order of magnitude of difference—.
5. The second abyss: under-engineering (lesson 6). The opposite error: refusing to leave a single seam and painting yourself into a corner, so that the probable change costs a rewrite. The lesson measures its cost when the change arrives.
6. The synthesis: designing the seams (lesson 7). The sensible point between the two abysses: a seam where the change is probable, defer where it isn't. Designing for change is not designing for every imaginable change. The lesson measures the right-sizing against the two extremes, and it wins.
Keep this map; it's the module's route:
Piece of the stance Lesson The idea in one sentence
────────────────────────────────── ──────── ─────────────────────────────────────
The architecture is a flow L2 think in film, not in photo
Optionality (open doors) L3 the option is worth a premium, under doubt
Sacrificial architecture L4 the scaffold is paid for to build well
The over-engineering abyss L5 YAGNI: don't build it until you need it
The under-engineering abyss L6 don't paint yourself into a corner
Designing the seams (the middle) L7 seam where the change is PROBABLE
────────────────────────────────── ──────── ─────────────────────────────────────
Design Mercado's evolution L8 the mini-project, executed
The map: where this module sits in the guide and the ecosystem
This module is the penultimate of the guide, and it closes the arc of the craft with the dimension of time. Here's how it connects with the rest:
flowchart TD
M1["M1 · What an architect actually does"]
M2["M2 · Conway's law"]
M3["M3 · Communicating architecture (C4)"]
M4["M4 · Technical leadership without authority"]
M5["M5 · Stakeholders and quality attributes"]
M6["M6 · Designing for change<br/>(the stance toward evolution)"]
M7["M7 · Documentation that survives"]
M8["M8 · Project: be Mercado's architect<br/>for a change"]
M1 --> M2 --> M3 --> M4 --> M5 --> M6 --> M7 --> M8
Read it like this: in modules 1 to 5 you installed the role, the org↔system dynamic, the communication, the leadership, and the translation of goals to attributes. Here, in M6, you add the stance toward time: the system is going to change, and the architect postures it to receive the change. In M7 you'll learn to document so the knowledge survives that change and the turnover of people. And in M8 you'll make the whole journey as Mercado's architect facing a real change.
And the frontier with the sister guide, which must be respected carefully because it's the closest of the whole ecosystem: architecture-decisions-and-tradeoffs teaches the mechanics of deciding under change —classify a decision by its reversibility (one-way or two-way doors), compute the last responsible moment, measure and pay technical debt—. That's technique, and its module 7 covers it in depth. This module teaches the mental stance of the one who embodies that technique: the disposition to plan for change, keep options, build to throw away, and avoid the two abysses. When in lesson 3 we talk about "keeping a door open", we won't re-teach how a one-way or two-way door is formally classified (that's the other guide); we'll teach why keeping doors open is part of what it means to be an architect. The distinction is the usual one in this guide: the tool against the craft of the one who wields it.
Common mistakes
These three mistakes are the three ways of failing in the face of change that the whole module fights. They appear here in summary form; each lesson opens one in depth.
Treating the architecture as final (the frozen design). What happens: the architect invests all their effort in the initial design, approves it, and then treats every business change as a nuisance that "breaks" the architecture, instead of as the normal state of a living system. The system fights against every new feature. Why it happens: the culture and the vocabulary push toward thinking in photos ("the system is this way"), not in films; and a finished design feels like an achievement to defend, not a hypothesis to revise. How to spot it: if every business change is lived as an architectural emergency, if you hear "that breaks the architecture" in the face of reasonable features, or if the system keeps accumulating patches because no one is willing to move it, the architecture is being treated as frozen. How to fix it: adopt the flow stance —the design is a hypothesis the business will correct— and posture the system to receive change with seams, instead of defending a design reality already invalidated. Lesson 2 measures it: the accumulated cost of the frozen stance is 2.7 times that of the fluid one.
Over-engineering: building for every imaginable future (breaking YAGNI). What happens: the architect, to "be prepared", builds flexibility, abstractions, and configuration layers for futures they imagine but that almost never come —the generic plugin system, the configurable rules engine, the microservices "because we're going to scale"—. The result is a complex system, expensive to maintain, whose flexibility no one uses. Why it happens: it comes from a good but miscalibrated place —the fear of painting into a corner— but it confuses "designing for the probable change" with "designing for every imaginable change". How to spot it: if there are abstractions with a single use case, configuration no one configures, or distributed infrastructure for traffic that doesn't exist, it's over-engineering. How to fix it: apply YAGNI —don't build the flexibility until the change is probable enough to pay for it— and measure the probability, not the fear. Lesson 5 quantifies it: pre-building all the imagined futures costs 25 times more than paying the rework of the ones that really come.
Under-engineering: painting into a corner (the opposite). What happens: the architect, out of misunderstood simplicity or haste, leaves no seam —everything calls everything, no boundaries, no abstractions— and when the probable change comes, there's nowhere to get in: it has to be rewritten. Why it happens: sometimes out of laziness, sometimes out of a naive reading of YAGNI ("don't prepare anything"), sometimes out of pressure to deliver fast without thinking about tomorrow. How to spot it: if a change the business was clearly going to ask for (a second payments provider, splitting a module into a service) implies a disproportionate rewrite because "everything is stuck together", you painted yourself into a corner. How to fix it: leave the cheap seam for the probable changes —not for all of them, but for those— which is exactly the sensible point. Lesson 6 measures it: rewriting with no seam costs 4.3 times more than having left the cheap seam. And lesson 7 shows that the art is in distinguishing the probable change (leave a seam) from the imagined one (don't).
Exercises
Exercise 1 — Photo or film? A new architect arrives at Mercado and, in a meeting, says: "I'm going to dedicate the next month to designing the definitive architecture of the system, so we don't have to touch it again for years". Using the half-life-of-the-design example, explain why that phrase reveals a wrong stance, and how an architect who designs for change would reframe the goal.
See solution
The phrase "the definitive architecture, so as not to touch it again for years" reveals the photograph stance: it believes there's a design you draw once and freeze. The half-life example shows why that's a ghost: in Mercado, by year 5 only 25% of the day-one design's assumptions is still in force —three quarters change in five years, not because of bad design but because the business moves—. A month of work to produce a "definitive" design is a month spent against a world that hasn't happened yet: 75% of that design is going to be wrong in five years no matter what, because you can't design against the future that hasn't come.
An architect who designs for change would reframe the goal like this: instead of "designing the definitive architecture", "designing an architecture that receives the foreseeable changes cheaply" —leaving seams where the business is probably going to press—. The question isn't "what's the right design forever?" but "when these assumptions fall —and they will— will my system be able to absorb the change or will it fight against it?". It's the difference between planning a photo and planning a film. The same month of work, well focused, doesn't produce a definitive design (impossible); it produces a system postured to evolve (which is what you can do).
Exercise 2 — The two abysses, in Mercado. For each of these two Mercado architect decisions, say which of the two abysses (over-engineering or under-engineering) it represents, and why: (a) "let's rewrite the monolith into 30 microservices now, with a service mesh and an event bus, because someday we're going to scale"; (b) "let's put all the payment logic directly in the checkout, reading and writing the payments tables from orders, that way it's faster to build".
See solution
(a) is over-engineering (breaking YAGNI). Rewriting the monolith into 30 microservices with a service mesh and event bus now —when the business "someday is going to scale" but isn't asking for it yet— builds enormous flexibility and complexity (networks, latency, eventual consistency, 30 deployments, the infrastructure of a distributed system) for an imagined future that might take years or come different from expected. It pays today the cost of a problem it doesn't have yet. The classic symptom: the justification is "just in case" / "someday", not a probable and near change. The correction is to keep the monolith and leave the seams to extract services when the business asks, not to build the 30 services in advance.
(b) is under-engineering (painting into a corner). Having orders read and write the payments tables directly erases the seam between the two modules: it sticks them into a ball with no boundary. It's faster to build today, yes, but when the business asks for something probable —a second payments provider, splitting payments into a service so a team owns it, complying with a regulation that isolates the payment data—, there'll be no line to cut along: the payment logic is tangled inside the checkout. The extraction will cost a rewrite. The classic symptom: today's speed was optimized by erasing a boundary the business probably was going to need. The correction is to leave the cheap seam —orders talks to payments through a clear interface, not by getting its hands into their tables—, which barely costs anything today and saves the rewrite tomorrow.
The whole module lives between these two abysses: (a) builds too much for the improbable; (b) builds too little for the probable. The sensible point (lesson 7) is to leave a seam where the change is probable —the payments/orders boundary of (b)— and not build where it's improbable —the 30 microservices of (a)—.
Exercise 3 — The right-of-way. Translate the urban-planner analogy to Mercado. The architect knows that, if the business grows, the catalog module will probably have to leave the monolith to its own service (to scale and for the catalog squad to own it whole). What would the "right-of-way" —the cheap seam left today— be for that future extraction, and why is leaving it now cheaper than opening the avenue later?
See solution
The "right-of-way" for the future catalog extraction is an architectural seam left today, cheaply, within the monolith, without building the separate service yet. Concretely, it would be something like: (1) that all catalog access pass through a clear interface (a module or a layer) instead of other modules reading the catalog tables directly —so the boundary exists even though today it's an in-memory call and tomorrow it's a network call—; (2) that the catalog data have its own tables, not intertwined with those of other modules in joins that would be impossible to split; (3) a defined contract of what the catalog asks for and returns, even though today it lives in the same process. None of that is building the microservice: it's leaving the strip of land reserved along which, the day it's needed, the avenue will be opened.
Why leaving it today is cheaper than opening the avenue later: if the seam isn't left and other modules read the catalog tables directly and do joins with them everywhere (under-engineering), extracting the catalog tomorrow means untangling all those dependencies —finding every place that touches the catalog tables, rewriting it to use an interface, migrating the data, breaking the joins—: a big and risky rewrite, like demolishing the houses built over the strip. By contrast, leaving the interface and the separate tables today costs almost nothing (it's a design decision, not significant extra code) and turns the future extraction into "changing the in-memory call for a network call" —cutting along the dotted line—. It's exactly the planner's right-of-way: the reserved strip barely costs anything, but it's the difference between opening the avenue without demolishing anything and expropriating half the city.
And the nuance that anticipates lesson 7: this is justified because the catalog extraction is a probable change (the business is going to grow, the squad is going to want to own it). For an improbable change —say, "turning Mercado into a white-label multi-tenant platform"— leaving the seam would not be justified: it would be reserving land for an airport that almost surely won't come (over-engineering). The right-of-way is reserved for the probable avenue, not for every imaginable infrastructure.
Summary and next step
In this lesson you installed the thesis that holds up the whole module: no architecture is final. It's not a photo that freezes on day one; it's a film, a flow of decisions that runs the whole life of the system. You measured it: in Mercado, 75% of the day-one design's assumptions are invalidated in five years —not because of bad design, but because the business moves—, so chasing the perfect and permanent diagram is chasing a ghost. You saw, with the three urban planners, that the craft is neither building the future in advance (over-engineering, the airport for three thousand inhabitants) nor painting yourself into a corner (under-engineering, the packed houses with no room for the avenue), but reserving the right-of-way: leaving the cheap seams where the probable change is going to pass. And you landed it all in Mercado: the architect who knows today's monolith will be services tomorrow, and postures it to let that service out without pain.
Before moving on you should be able to: explain why "the definitive design" is a ghost using the half-life idea; distinguish the two abysses (over-engineering and under-engineering) with a Mercado example; and translate "leaving a seam" into the right-of-way analogy —cheap today, decisive tomorrow—.
Lesson 2 takes the first piece of the stance and develops it in depth: architecture as a flow of decisions, not as a frozen artifact. You'll see why what breaks a system isn't one big change, but the accumulation of changes against a structure that wasn't designed to move —and execute the accumulated cost of the frozen stance against the fluid one over the life of Mercado—. With numbers, so that "the architecture is a flow" stops being a slogan and becomes a measurement.
Resources
- Martin Fowler, "Sacrificial Architecture" (2014) — martinfowler.com/bliki/SacrificialArchitecture.html. The text that names one of the module's pieces (lesson 4): building knowingly something that will be replaced. Fowler starts from the fact that no architecture is final, this lesson's thesis. Short and essential. In English.
- Martin Fowler, "Yagni" (2015) — martinfowler.com/bliki/Yagni.html. The source of the YAGNI line lesson 5 works: why building for imagined futures almost always comes out expensive. In English.
- Neal Ford, Rebecca Parsons, and Patrick Kua, Building Evolutionary Architectures (O'Reilly, 2017) — the module's central book. Its premise is exactly this guide's: architecture must be designed to evolve, because change is the constant. In English.
- Mark Richards and Neal Ford, Fundamentals of Software Architecture, 2nd ed. (O'Reilly, 2020), ch. 3–4 ("Modularity / Architecture Characteristics") — the framework of why internal boundaries (the seams) matter and how they're thought about. In English.
- Andrew Hunt and David Thomas, The Pragmatic Programmer, 20th Anniversary Edition (Addison-Wesley, 2019), topics "Reversibility" and "Good-Enough Software" — the root of the stance: there are no final decisions, and the software that evolves well is the one that didn't marry irreversible assumptions. In English.