Module 2: Understanding and Stabilizing the Legacy System

Mini-project: pin Mercado's catalog pricing

Next →

Overview

The moment has come to put it all together. In the previous seven lessons you learned the pieces separately: what a characterization test is and why it pins behavior instead of correctness, how to write it by capturing instead of guessing, how to open a seam when a dependency prevents it, how to scale with sampling and a golden master, what to do with the quirks someone depends on, and in what order to apply it all. This mini-project puts you to using the pieces together, end to end, over the module's real goal: leave Mercado's catalog module completely pinned —with a real safety net—, so it's ready for what comes in module 3, when we start putting it behind a strangler facade and diverting traffic to it.

The deliverable isn't an essay: it's executed code plus a note. When you finish you'll have (1) a golden master of hundreds of catalog prices, recorded with reproducible sampling; (2) the seams that make the characterization deterministic —the tax rate and the clock parameterized—; (3) the gold quirk characterized and documented, not deleted, with a note that explains who depends on it; and (4) the proof that you can change under the net —a legible refactor that passes green, and a risky "fix" that the net catches red—. Those four artifacts are exactly what module 3 needs to start migrating safely: without them, diverting traffic to the new service would be a blind bet.

Connection with the module. This lesson teaches nothing new: it integrates the previous seven into a single flow and executes it over a complete case. It's the close of module 2 and the hinge toward the rest of the guide. The net you build here is the one that in module 3 will certify that the catalog served by the new path reproduces exactly what the old one served (if the golden master stays green against the new service, the traffic diversion is safe); in module 4, the one that will protect the migration of the implementation from the inside. The boundary is respected to the end: here we pin the catalog; diverting its traffic is M3, extracting it into a service is M5, and the formal decision to correct the quirk (with its ADR) is the architecture-decisions guide. This project delivers the net; it doesn't cross those lines.

An analogy: the dossier you hand to the next team

Imagine you renovated the bathroom —you took the "before" photos, marked where the pipes and the shutoff valve run, noted that the crooked wall holds up the roof— and now you have to hand the job over to another team that's going to continue with the kitchen. It's not enough to say "it's done, continue": you hand them a dossier. The photos of the original state (so they know what to compare against), the map of where the critical installations are (so they don't break a pipe by mistake), and a big, visible note about the crooked wall ("do NOT knock down: it's load-bearing, the neighbor above depends on it"). With that dossier, the next team can work with confidence: they know what was there, what not to touch, and how to verify they didn't break anything. Without it, they start blind —exactly the state you started from—.

The deliverable of this project is that dossier, for Mercado's catalog. The golden master is the photos of the original state. The seams are the documented shutoff valves (the clock comes in here, the tax rate here). The note about the gold quirk is the "do NOT knock down without notifying the partner" sign. And the demonstration that a refactor passes green and a "fix" red is the proof that the dossier works —that the net actually distinguishes the safe from the dangerous—. When module 3 takes this catalog to migrate it, it'll work with your dossier in hand. The quality of that dossier is what decides whether the migration advances with confidence or gropes its way forward.

The project, executed: the catalog's complete dossier

Here's the project end to end. Read the code as the flow that integrates the seven lessons: seams (tax rate and clock parameterized), golden master by sampling of 400 inputs, the quirk documented, and two changes under the net —a legible refactor and a "fix" that breaks the quirk—.

import math
import random
from datetime import date

CATEGORY_DISCOUNT = {"electronics": 0.05, "books": 0.10, "toys": 0.08, "grocery": 0.00}
BULK_MIN_QTY, BULK_DISCOUNT, GOLD_LOYALTY_DISCOUNT = 10, 0.05, 0.03


def _floor_cents(a):
    return math.floor(a * 100) / 100


# --- Legacy with SEAMS: tax_rate and today enter as parameters with a default ---
def legacy_catalog_price(item, tax_rate=0.16, today=None):
    if today is None:
        today = date.today()
    price = _floor_cents(item["unit_price"] * item["quantity"])
    price = _floor_cents(price * (1 - CATEGORY_DISCOUNT.get(item["category"], 0.0)))
    if item["quantity"] >= BULK_MIN_QTY:
        price = _floor_cents(price * (1 - BULK_DISCOUNT))
    coupon = item.get("coupon_percent", 0.0)
    if coupon and (not item.get("coupon_expires") or today <= item["coupon_expires"]):
        price = _floor_cents(price * (1 - coupon))
    price = _floor_cents(price * (1 + tax_rate))
    if item.get("loyalty") == "gold":                 # QUIRK: gold post-tax
        price = _floor_cents(price * (1 - GOLD_LOYALTY_DISCOUNT))
    return price


def generate_catalog_inputs(n, seed=2026):
    rng = random.Random(seed)
    cats = list(CATEGORY_DISCOUNT)
    items = []
    for i in range(n):
        items.append({
            "sku": f"CAT-{i:04d}",
            "unit_price": round(rng.uniform(1, 400), 2),
            "quantity": rng.randint(1, 20),
            "category": rng.choice(cats),
            "coupon_percent": rng.choice([0.0, 0.0, 0.10, 0.15]),
            "coupon_expires": date(2026, 12, 31),
            "loyalty": rng.choice([None, None, None, "gold"]),
        })
    return items


FIXED_TODAY = date(2026, 7, 1)     # fixed clock -> deterministic
FIXED_TAX = 0.16                   # fixed rate -> deterministic
inputs = generate_catalog_inputs(400)

# 1) GOLDEN MASTER: the photo of "how the catalog charges today".
golden_master = {
    it["sku"]: legacy_catalog_price(it, tax_rate=FIXED_TAX, today=FIXED_TODAY)
    for it in inputs
}
print("== 1. Safety net: golden_master of the catalog ==")
print(f"   {len(golden_master)} prices pinned with tax={FIXED_TAX}, today={FIXED_TODAY}")

# 2) Check that the net is GREEN against the legacy itself (control).
selfcheck = sum(
    1 for it in inputs
    if legacy_catalog_price(it, tax_rate=FIXED_TAX, today=FIXED_TODAY)
    != golden_master[it["sku"]]
)
print(f"   self-check legacy vs golden_master: "
      f"{'GREEN' if selfcheck == 0 else 'RED'} ({selfcheck} failures)\n")

# 3) The quirk documented, not deleted.
print("== 2. Quirk characterized (not 'fixed') ==")
gold_orders = [it for it in inputs if it.get("loyalty") == "gold"]
print(f"   {len(gold_orders)} gold orders in the batch apply the loyalty AFTER")
print("   the tax. It stays pinned in the golden_master. Note for the team:")
print("   'the partner's rebate depends on this number; changing it is a business")
print("    decision, not a technical cleanup.'\n")


# 4) SAFE refactor behind the net.
def refactored_catalog_price(item, tax_rate=0.16, today=None):
    if today is None:
        today = date.today()

    def step_base(it):
        return _floor_cents(it["unit_price"] * it["quantity"])

    def step_category(p, it):
        return _floor_cents(p * (1 - CATEGORY_DISCOUNT.get(it["category"], 0.0)))

    def step_bulk(p, it):
        return _floor_cents(p * (1 - BULK_DISCOUNT)) if it["quantity"] >= BULK_MIN_QTY else p

    def step_coupon(p, it):
        c = it.get("coupon_percent", 0.0)
        if c and (not it.get("coupon_expires") or today <= it["coupon_expires"]):
            return _floor_cents(p * (1 - c))
        return p

    price = step_base(item)
    price = step_category(price, item)
    price = step_bulk(price, item)
    price = step_coupon(price, item)
    price = _floor_cents(price * (1 + tax_rate))
    if item.get("loyalty") == "gold":
        price = _floor_cents(price * (1 - GOLD_LOYALTY_DISCOUNT))
    return price


# 5) A "fix" that breaks the quirk (gold pre-tax).
def cleaned_catalog_price(item, tax_rate=0.16, today=None):
    if today is None:
        today = date.today()
    price = _floor_cents(item["unit_price"] * item["quantity"])
    price = _floor_cents(price * (1 - CATEGORY_DISCOUNT.get(item["category"], 0.0)))
    if item["quantity"] >= BULK_MIN_QTY:
        price = _floor_cents(price * (1 - BULK_DISCOUNT))
    coupon = item.get("coupon_percent", 0.0)
    if coupon and (not item.get("coupon_expires") or today <= item["coupon_expires"]):
        price = _floor_cents(price * (1 - coupon))
    if item.get("loyalty") == "gold":
        price = _floor_cents(price * (1 - GOLD_LOYALTY_DISCOUNT))
    return _floor_cents(price * (1 + tax_rate))


def run_suite(fn, label):
    fails = [it["sku"] for it in inputs
             if fn(it, tax_rate=FIXED_TAX, today=FIXED_TODAY) != golden_master[it["sku"]]]
    print(f"   characterization_suite vs {label}:")
    print(f"     {len(inputs)-len(fails)} passed, {len(fails)} failed  ==> "
          f"{'GREEN' if not fails else 'RED'}")
    if fails:
        print(f"     examples: {', '.join(fails[:4])} ...")
    return len(fails)


print("== 3. Change under the net ==")
run_suite(refactored_catalog_price, "the legible REFACTOR (same behavior)")
run_suite(cleaned_catalog_price, "the 'fix' of the gold quirk (changes behavior)")
print()
print("== Deliverable ==")
print("   [x] golden_master of 400 prices (the photo of today's catalog)")
print("   [x] seams: tax_rate and today parameterized (deterministic test)")
print("   [x] gold quirk documented and pinned, not deleted")
print("   [x] legible refactor delivered GREEN")
print("   [x] risky 'fix' caught RED before production")
print("   Ready for M3: put the catalog behind a strangler facade.")

What to expect. When you run the file, the output is exactly this:

== 1. Safety net: golden_master of the catalog ==
   400 prices pinned with tax=0.16, today=2026-07-01
   self-check legacy vs golden_master: GREEN (0 failures)

== 2. Quirk characterized (not 'fixed') ==
   86 gold orders in the batch apply the loyalty AFTER
   the tax. It stays pinned in the golden_master. Note for the team:
   'the partner's rebate depends on this number; changing it is a business
    decision, not a technical cleanup.'

== 3. Change under the net ==
   characterization_suite vs the legible REFACTOR (same behavior):
     400 passed, 0 failed  ==> GREEN
   characterization_suite vs the 'fix' of the gold quirk (changes behavior):
     362 passed, 38 failed  ==> RED
     examples: CAT-0000, CAT-0010, CAT-0011, CAT-0016 ...

== Deliverable ==
   [x] golden_master of 400 prices (the photo of today's catalog)
   [x] seams: tax_rate and today parameterized (deterministic test)
   [x] gold quirk documented and pinned, not deleted
   [x] legible refactor delivered GREEN
   [x] risky 'fix' caught RED before production
   Ready for M3: put the catalog behind a strangler facade.

Walk through the dossier section by section, because each one is a lesson of the module made artifact.

Section 1 —the golden master— is the complete safety net. 400 catalog inputs were generated by reproducible sampling (seed 2026) and their 400 prices were recorded as the photo of "how it charges today." Notice the crucial detail: they were recorded with tax=0.16 and today=2026-07-01 fixed. That's what makes the photo sharp instead of blurry —without fixing those two dependencies, each run would give different numbers and the golden master would mean nothing—. The self-check comes out green (0 failures): the legacy against its own golden master matches, as it should. The net is stretched.

Section 2 —the quirk documented— is the dossier's note. Of the 400 orders, 86 are gold customers, and all apply the loyalty after the tax —the quirk—. The project doesn't delete it: it pins it in the golden master and puts an explicit note on it for the next team: "the partner's rebate depends on this number; changing it is a business decision, not a technical cleanup." That sign is what keeps the next developer from knocking down the load-bearing wall without knowing. The quirk went from being hidden in the code to being documented and protected.

Section 3 —change under the net— is the proof that the dossier works. Two changes were made to the catalog, under the same net of 400 prices. The legible refactor —which extracted each step to a named function (step_base, step_category, etc.), preserving the order and the rounding, and keeping the gold quirk after the tax— passes green: 400 of 400. The net certifies that, despite reorganizing the whole function, the behavior is identical. The "fix" of the quirk —which moved gold to before the tax— passes red: 38 failures (the gold cases where the rounding makes the cent fall differently). The net caught, before production, exactly the change that would have broken the reconciliation with the partner from lesson 6. A safe change and a dangerous change, distinguished objectively by the referee.

And the deliverable closes the module: five boxes checked, and the line that matters —"ready for M3"—. The catalog is no longer code that's scary to touch; it's code with a net, with documented seams, with its quirk flagged, and with the proof that the net distinguishes the safe from the dangerous. That's exactly what module 3's strangler facade needs to start diverting traffic to it with confidence.

Deep dive: why this dossier is the prerequisite of the whole migration

It's worth making explicit why module 3 —and everything that follows— can't start without this dossier. The strangler fig, which you'll see in M3, works by putting a facade in front of the catalog that routes part of the traffic to the new service and the rest to the old one, and it raises the new one's percentage from 0 to 100 until it turns off the old. The question that decides whether that's safe is a single one: does the new service do exactly what the old one did?. And that question only has an answer if you have the golden master. With it, you run the new service against the 400 pinned inputs and compare: if it comes out green, the new one reproduces the old one's behavior —including the gold quirk, including every rounding decision— and you can divert traffic to it with confidence. If it comes out red, the new one differs in something, and diverting traffic to it would charge different prices to real customers. The golden master turns "I think the new service is fine" into "I verified it against 400 cases."

That's why the guide's order is what it is. You can't divert traffic (M3) without the net (M2). You can't migrate the implementation from the inside (M4) without the net. You can't extract the service (M5) without the net that guarantees the extracted one behaves like the original. This project's net is the foundation, and the seams are an essential part of that foundation: without parameterizing the clock and the tax rate, you couldn't even record a reproducible golden master —each run would give a different photo—. The dossier isn't an optional quality step; it's the technical condition that makes everything that comes verifiable.

There's one last piece of the dossier worth naming, because it's the one that ties this module to lesson 6 and to the decisions guide: the note about the quirk is a handoff of tacit knowledge. Module 1 warned that rewrites fail in part because they lose the tacit knowledge buried in the legacy —rules won over years that nobody documented—. This project does the opposite: it takes one of those tacit rules (gold after the tax, the partner's rebate) and makes it explicit —it pins it in a test, puts a note on it, points at the dependent—. Each quirk you characterize and document is a piece of tacit knowledge rescued from oblivion. Incremental migration wins, in part, because it goes on turning that invisible knowledge into visible artifacts, slice by slice, instead of throwing it in the garbage of a big-bang.

flowchart TD
    P["Catalog dossier (M2)"] --> GM["golden_master<br/>(400 pinned prices)"]
    P --> SE["seams<br/>(tax_rate + today)"]
    P --> NOTE["quirk note<br/>(gold: the partner depends)"]
    GM --> M3["M3: strangler facade<br/>divert traffic if the new == golden_master"]
    SE --> M3
    NOTE --> M3
    M3 --> M5["M5: extract the service<br/>with the net guaranteeing parity"]

Common mistakes

Delivering the golden master without the seams, with a non-reproducible photo. What happens: the golden master is recorded but the legacy keeps consulting the real clock and the tax global inside, so the photo changes depending on the day and the configuration. Why it happens: recording the numbers feels like "the net is done," and the seams seem like a later refinement. How to spot it: if you run the recording on two different days and the golden master comes out different, the photo is blurry and isn't good for comparing. How to fix it: the seams aren't optional for a reproducible golden master —they're what fixes the non-deterministic dependencies so the photo is always the same—. This project recorded with tax=0.16 and today=2026-07-01 fixed precisely for that. Without seams, module 3 couldn't compare the new service against a stable photo, because the photo would move on its own.

Deleting or "cleaning up" the quirk on delivery, instead of documenting it. What happens: when assembling the dossier, the team takes the chance to "leave the catalog pretty" and corrects the gold quirk before delivering. Why it happens: delivering "clean" code feels like delivering better work. How to spot it: if the golden master you deliver no longer contains the quirk (the gold prices come out 106.89 instead of 106.88), you changed the behavior you were supposed to preserve. How to fix it: the dossier must pin the current behavior, quirk included, and document it —not delete it—. The quirk is a de facto contract (the partner depends, lesson 6); correcting it is a coordinated business decision, not a delivery cleanup. A "cleaned" golden master is worse than useless: it hands module 3 a photo of a catalog that doesn't exist, and when the new service reproduces the real behavior (with the quirk), the net will come out red against the wrong photo.

Considering the project finished without proving that the net catches something. What happens: the golden master is recorded, comes out green against the legacy itself, and the net is declared ready —without ever proving it detects a real change—. Why it happens: the green of the self-check gives a sense of completeness. How to spot it: if you never ran the net against an implementation different from the legacy, you don't know whether it really catches regressions or whether it always comes out green by coincidence (for example, if the golden master had a bug that makes it match everything). How to fix it: a net isn't validated until you see it turn red faced with a behavior change —that's why this project runs the "fix" of the quirk and confirms the 38 failures—. The red of the dangerous change is as much part of the deliverable as the green of the safe refactor: together they prove the net distinguishes, that it's not a traffic light stuck on green. Delivering a net you've never seen in red is delivering a smoke detector without having pressed the test button.

Exercises

Exercise 1 — Extend the dossier. The project's golden master was recorded with random sampling of 400 inputs. A reviewer points out that, even though 86 gold cases came out, the sampling doesn't guarantee covering the volume-threshold edge (quantity exactly 10). Describe how you'd extend generate_catalog_inputs to seed on purpose the catalog's critical edge cases, and explain why that makes the dossier more robust for module 3.

See solution

I'd extend the generation by combining the reproducible random sampling with a block of forced edge cases that are always added, independently of chance. Concretely, I'd explicitly seed:

  • The volume threshold: for several prices and categories, items with quantity fixed at 9, 10, and 11 —the three points around BULK_MIN_QTY—, to pin both the case without volume discount (9), the exact edge (10), and the next (11).
  • All the categories, including grocery (0 discount): at least several items of each category, so each one's branch gets pinned, including the one that "doesn't discount."
  • Valid vs expired coupon: items with coupon_expires before and after FIXED_TODAY, to pin both branches of the coupon (the clock seam makes this deterministic).
  • Gold customers in guaranteed proportion: an explicit block of gold cases (for example, combined with each category and with a coupon), so as not to depend on chance producing enough —and enough of the ones that manifest the quirk, not just the ones that absorb it in the rounding—.

These forced cases are concatenated with the 400 (or however many) random inputs with a fixed seed, which keep sweeping the general space.

Why it makes the dossier more robust for M3: the golden master is the yardstick against which module 3 will measure whether the new service reproduces the old one. If that yardstick has holes at the edges —it doesn't pin the volume threshold, doesn't cover grocery, doesn't include an expired coupon—, then a new service that gets it wrong right at those edges would pass the comparison green, and the error would be diverted to production when the traffic reached a customer with quantity 10 or an expired coupon. Seeding the edges closes those holes: it guarantees the photo covers the fine points where the legacy is most fragile, so any divergence of the new service at those points is detected before diverting traffic to it. A yardstick with holes gives false confidence to the whole migration that rests on it.

Exercise 2 — Simulate the handoff to M3. Module 3 is going to build a modern_catalog_price (a new service) that must reproduce the legacy's behavior. Describe, using this project's golden master, the exact procedure with which module 3 would verify that it's safe to start diverting traffic to it. What result of the procedure would give a green light, and what result would force stopping the diversion?

See solution

The procedure is a parallel-run of the new service against this project's golden master:

  1. Run the new service over the same 400 pinned inputs, with the same seam values (tax_rate=0.16, today=2026-07-01) with which the golden master was recorded —to compare against the same scene—.
  2. Compare, input by input, the output of modern_catalog_price against golden_master[sku], counting and listing the discrepancies.
  3. Read the result:
    • Green light (400 passed, 0 failed): the new service reproduces exactly the legacy's behavior for the 400 inputs —including the gold quirk (gold prices at 106.88, not 106.89), including the step-by-step rounding, including the threshold and coupon branches—. It's safe to start diverting traffic to it, because any customer who lands on the new service will receive the same price the old one gave them.
    • Stop the diversion (any failed > 0): the new service differs from the legacy in at least one case. The diff says exactly which and how. Diverting traffic now would charge different prices to real customers in those cases. The new service has to be fixed so it reproduces the behavior (bug-for-bug, quirk included) and the parallel-run rerun until it comes out green.

The key point of the handoff: module 3 doesn't decide "the new service looks fine, let's start"; it decides with the evidence of the golden master. This project's net is what turns the traffic diversion from a bet ("I hope the new one is fine") into a verified operation ("I compared the new one against 400 cases of the old one and they match"). That's why the dossier is the prerequisite of M3: without it, there'd be no objective way to give the green light.

Exercise 3 — The incomplete dossier. A colleague delivers their version of the project like this: they recorded the golden master, but (a) recorded it without fixing today (used the real clock), (b) "along the way" corrected the gold quirk to leave the code clean, and (c) never ran the net against any implementation different from the legacy. For each of the three problems, explain what breaks and how you'd detect it, and say which of the three is the most dangerous for module 3 and why.

See solution
  • (a) Golden master without fixing today: the photo isn't reproducible —it depends on the day it was recorded, because the coupons' validity changes with the clock—. Comparability breaks: if module 3 runs the parallel-run another day, the golden master no longer matches even the legacy itself, and the net gives false reds (or false greens) because of the calendar, not the behavior. How to detect it: re-record on two different dates and see that the golden master changes without anyone having touched the code. The fix is to use the clock seam with a fixed date, as the project did (today=2026-07-01).
  • (b) "Corrected" the gold quirk: the golden master now pins a behavior the legacy doesn't have (gold prices at 106.89 instead of 106.88). The photo's fidelity breaks: it no longer portrays the real catalog. How to detect it: compare the colleague's golden master against the real legacy —it would come out red on the gold cases—, or notice that no gold price ends in the expected quirk. Besides, it deleted a de facto contract (the partner's rebate) without coordination.
  • (c) Never saw the net in red: there's no proof that the net detects changes; it could be always green because of an error. The validation of the net itself breaks. How to detect it: run it against a deliberately different implementation (like the project's "fix") and confirm it turns red; if it doesn't, the net is useless.

The most dangerous for M3 is (b), the "corrected" quirk. The reasons: (a) produces noisy failures —reds or greens that don't add up because of the calendar— that someone will notice and investigate; it's a visible problem. (c) leaves the net unvalidated, but as long as the legacy and the new one really match, it causes no active immediate damage. In contrast (b) is silent and actively deceptive: the golden master looks perfectly healthy and comes out green against itself, but it portrays a catalog that doesn't exist. When module 3 builds the new service reproducing the legacy's real behavior (with the quirk, which is the correct thing during the migration), the parallel-run will come out red against the false photo, and the team might "fix" the new service to match the wrong photo —propagating the uncoordinated correction of the quirk to the new system and breaking the partner, all while thinking it's doing the right thing—. An unfaithful photo corrupts all the decisions that rest on it; it's the error that reaches furthest.

Summary and next step

With this mini-project you closed module 2 by delivering the complete dossier of Mercado's catalog: a golden master of 400 prices recorded by reproducible sampling, the seams (tax rate and clock) that make it deterministic, the gold quirk characterized and documented —not deleted—, and the proof that the net distinguishes the safe from the dangerous (a legible refactor green, 400/400; a "fix" of the quirk red, 38 failures). You saw, with the dossier you hand to the next team, that the net isn't a quality ornament: it's the knowledge handoff that makes the whole migration to come verifiable. The catalog went from being code that's scary to touch to being code with a net, with seams, with its quirk flagged, and with the guarantee that any change can be judged objectively.

With this you completed the whole module. Now you can: pin the behavior of a legacy function with a characterization test; open seams to make it deterministic; scale the characterization with sampling and a golden master; recognize and document the quirks someone depends on; and apply the five-step discipline —read, seam, characterize, change, let the net decide— to change without fear.

Module 3 takes this pinned catalog and takes the first step of the real migration: the strangler fig pattern. You're going to put a facade in front of the catalog, build the new service beside it, and divert traffic incrementally —from 0% to 100%— with the old route as fallback, until you turn off the legacy. And at each step of that diversion, the net you built in this project will be the one that guarantees the new service does exactly what the old one did —gold quirk included—. For the first time in the guide, you're going to move traffic from the old to the new, and you're going to do it safely because the catalog is already pinned. The dossier is ready; the work begins.

Resources

  • Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004) — the whole book as the project's reference: characterization tests (ch. 13), seams (ch. 4), and the flow of putting code under test before changing it. This module's toolbox. In English.
  • Martin Fowler, "StranglerFigApplication" — martinfowler.com/bliki/StranglerFigApplication.html. Where this dossier goes: the pattern module 3 will use to divert traffic from the old catalog to the new one, resting on the net you built here. In English.
  • Sam Newman, Monolith to Microservices (O'Reilly, 2019), ch. 3 "Splitting the Monolith" — how a piece of the monolith (like the catalog) is prepared and extracted, and why the characterization net is the prerequisite of the extraction. The bridge from M2 to M3 and M5. In English.
  • Martin Fowler, "Patterns of Legacy Displacement" — martinfowler.com/articles/patterns-legacy-displacement. The procedure with which module 3 will verify the new service against this project's golden master: run both and compare; the parallel run as a named pattern is from Sam Newman (Monolith to Microservices). In English.
← PreviousRead and characterize before you changeNext →Module introduction: the strangler fig pattern