DEV Community: Suprie

The NUMMI Blueprint for AI: Why Code Velocity Needs the Andon Cord

Suprie — Sat, 10 Oct 2026 00:01:07 +0000

I first heard about NUMMI years ago on an episode of This American Life. Toyota took over one of General Motors’ worst factories in Fremont, California, rehired many of the same workers, and turned it into one of its best plants. As software engineering enters the era of AI-generated code, NUMMI offers a crucial lesson: increasing speed without built-in mechanisms for quality only helps you produce defects faster.

One of GM’s Worst Factories

In the early 1980s, GM closed its Fremont plant due to chronic absenteeism, grievances, strikes, and deliberate sabotage. The prevailing view was simple: the workers were the problem.

When Toyota created the NUMMI joint venture in 1984, they rehired those exact same workers and sent union leaders to Japan to study the Toyota Production System. They learned that quality was not enforced by end-of-line inspectors—it was built into every step by the people doing the work. The workers returned and transformed GM’s worst plant into a model of efficiency.

The Cord and the Flow

At the heart of NUMMI’s success was the andon cord. If a worker found a defect, they pulled a cord to call for help, stopping the line if necessary. At GM, workers were forced to let defects move downstream, where they became exponentially more expensive to fix. Toyota viewed a defect moving downstream as a failure, treating problem discovery not as an error, but as an opportunity to fix the system.

Modern software engineering digitized this concept:

commit → build → test → deploy → production

CI/CD, automated testing, feature flags, and instant rollbacks are simply digital andon cords designed around flow—producing in small batches to get immediate feedback and contain damage early.

Kaizen and Culture

Toyota also practiced kaizen (continuous improvement) by listening to the factory floor. They built simple fixtures and tools to eliminate awkward movements, recognizing that the person doing the job daily understands friction better than management. In software, we call this developer experience: internal platforms, faster CI builds, and local setup scripts.

NUMMI demonstrated that ordinary people inside a good system produce extraordinary results, while talented people trapped in a bad system eventually look incompetent. But culture cannot be a motivational poster.

Culture is not what leadership writes on the wall.

Culture is what the system rewards when something goes wrong.

Now We Have AI

AI has made generating software fast and cheap. However, using AI purely to maximize volume leads directly to AI slop: unmaintainable code, superficial test coverage, hallucinated documentation, and over-engineered abstractions.

AI makes bad engineering practices scale just as quickly as good ones. If AI generates code ten times faster, our feedback loops must adapt. Automated tests, strict observability, clean architecture, and human comprehension become more critical, not less. The goal should not be "How much more code can we generate?" but rather "How can AI remove friction so humans can think better?"

The AI Andon Cord

Because AI agents can generate fifty "stations" of work before a human steps in, we need explicit circuit breakers to stop runaway generation:

Tests fail? Stop.
Scope creeps beyond the task? Stop.
The diff exceeds readable limits? Stop.
Architecture grows unnecessarily complex? Stop.

The faster we generate, the more valuable the ability to stop becomes.

Don’t Ask AI to Move the Line Faster

Engineering leaders must resist measuring AI solely through output metrics like lines of code or closed tickets. Go to where the work happens: sit with engineers, identify where AI adds friction, and build guardrails around it.

Without the right system, AI simply speeds up the production of bad software. With the right system—and an andon cord built for AI—it becomes the ultimate tool in an engineer's hands.

Idempotency Part 2: The Backend Contract - Why ON CONFLICT Is Not Enough

Suprie — Sat, 03 Oct 2026 16:27:17 +0000

The Real Problem Is Not Duplicate Requests

The naive backend implementation looks safe until two requests arrive at the same time. Both check whether an idempotency key exists. Both see nothing. Both create an order.

That is a time-of-check to time-of-use race. Checking the key in application code does not reserve it.

Postgres can arbitrate that race with a primary key on (user_id, key) and INSERT ... ON CONFLICT DO NOTHING. Among competing transactions that successfully commit, only one can claim that key.

But winning the claim is only the beginning.

If you commit the key and then create the order in a separate transaction, the process can crash between those steps. The key says processing, but there is no order to process. Every retry finds the same unfinished claim.

The fix is to commit the idempotency record and the order together. That protects order creation. Protecting what happens outside Postgres requires another guarantee.

High-Level Architecture

The flow starts with four components. The iOS client sends an order with an Idempotency-Key header. The Rust API opens a Postgres transaction, claims the key, creates the order, and links the two records. It commits before calling the matching engine.

Postgres holds the durable state for both the original request and its retries. Redis is unnecessary for correctness in this design.

If the API crashes before commit, neither record becomes committed, and a retry can try again. If it crashes after commit but before calling the matching engine, the order remains pending, and a background reconciler can recover it.

There is one more failure window: the matching engine accepts the order, but the API crashes before recording that result. Postgres still says pending. A reconciler might submit the order again.

To make that recovery safe, the matching engine must recognize a repeated submission using a stable identifier, such as the order ID. The database transaction prevents duplicate order creation; downstream deduplication prevents duplicate execution.

Designing the Table to Store Intent, Not Just Keys

An idempotency record needs to describe the request and its outcome. A useful schema includes:

A primary key on (user_id, key).
A request fingerprint for detecting changed payloads.
The order ID created for that request.
A processing status.
The response status and body, once available.
An expiration timestamp.

If the table serves multiple operations, include the operation in the key scope or explicitly require keys to be unique across those operations.

Define the fingerprint deliberately. Hashing raw JSON bytes treats changes in whitespace or field order as different requests. For an order API, hashing a normalized representation of the validated order fields may better capture the intent.

Persisting the response lets retries replay the original outcome without rebuilding it from an order whose state may have changed. Storing JSON in jsonb preserves its content, but does not promise the original byte representation.

The IETF Idempotency-Key draft recommends returning the result of a previously completed operation. It also recommends 422 when the same key is reused with a different payload and 409 when the original operation is still outstanding. These are draft recommendations, rather than a requirement for byte-identical response replay.

ACID in Practice

Atomicity: Claim and Order Must Commit Together

Begin a transaction and try to insert the idempotency record.

If the insert succeeds, create the order and link it to the claim within that same transaction. Commit both records together.

If the insert does not create a row, end that transaction and read the existing record in a fresh transaction. A competing insert can wait for the winning transaction to finish, so a conflict does not necessarily mean that the entire business operation has completed.

The existing record determines the next step:

A different fingerprint returns 422.
A completed operation returns its stored result.
An outstanding operation follows the API’s documented concurrent-request behavior.

For this design, that last case returns 409. An asynchronous API can instead define order acceptance as the completed operation, persist a 202 acceptance response alongside the order, and expose matching progress through a separate endpoint.

The important point is to choose a clear contract. “Order accepted” and “order matched” are different outcomes.

Consistency: A Key Identifies One Intent

Reusing the same key for a different payload must not silently return an unrelated order.

Store the fingerprint when claiming the key and compare it on every duplicate request. A view-model bug that reuses a key for a different symbol should produce an explicit error.

The idempotency key does not replace business constraints. Balance checks, valid order transitions, and other invariants still need their own enforcement.

Isolation: Let the Unique Index Arbitrate the Claim

Do not rely on SELECT followed by INSERT to decide who owns the request. Both transactions can observe that the key is absent.

Use the unique constraint to arbitrate ownership. Under PostgreSQL’s default Read Committed isolation, retrieve the existing record with a subsequent read after the conflicting insert finishes.

For later state transitions, use conditional updates or row locks where necessary. If both the API and a reconciler can process pending work, they also need coordination to avoid unnecessary concurrent submissions.

That coordination reduces overlap. The matching engine’s deduplication guarantee still handles retries after uncertain outcomes.

Durability: Persist the Outcome Before Responding

After the matching engine returns a definitive result, update the order and idempotency record together in a second transaction. Store the response, commit, and then respond to the client.

If the API crashes after that commit but before the client receives the response, a retry can retrieve the stored outcome.

If it crashes before recording the result, the original claim and order still exist. The retry does not need to create another order. Recovery must resolve the existing order’s outcome, either by querying the matching engine or by safely resubmitting the same order ID.

This guarantee assumes Postgres is configured for durable commits. ACID protects the records in Postgres; it cannot make an external call part of the same transaction.

Walking Through the Crash Windows

Failure point	Durable state	Recovery
Before the first commit	No committed claim or order	Retry can claim and create
After commit, before submission	Claim and pending order	Reconciler submits the existing order
After engine acceptance, before recording the result	Claim and apparently pending order	Query the engine or resubmit with downstream deduplication
After recording the result, before responding	Completed record and stored response	Retry replays the result

The third row is the easy one to miss. A timeout or crash does not tell you whether the external operation happened.

How Long to Keep the Key

Retention is part of the API contract.

Twenty-four hours might suit some order workflows. Other systems may need several days or longer. Choose the window based on client retries, offline behavior, recovery time, and the consequences of replaying an old request.

Deleting a key ends its deduplication protection. A late retry may then look like a new request.

Publish the expiration policy, and avoid deleting unresolved records merely because their original retry window has elapsed.

Closing

Mobile taught me to distrust the network. Backend taught me to distrust my own process crashing between two lines of code.

Idempotency is where those two distrusts meet.

A transaction makes the request’s intent durable. A stored response makes the outcome repeatable. Once execution crosses a service boundary, the receiving system must recognize that same intent too.

Next: Where COMMIT Is Not Enough — The Transactional Outbox

The diagram still contains a gap: we commit the order, then call the matching engine.

A reconciler can recover pending orders, but we can represent the intent to publish explicitly. Instead of relying on an immediate call after commit, insert an outbox event in the same transaction as the order and idempotency claim.

The transaction now commits three things together:

The request’s idempotency record.
The order.
The durable intent to publish that order.

A separate relay reads committed outbox events, publishes them, and marks them as sent.

This moves the intent to publish inside the database transaction. The external publication still happens outside it.

If the relay publishes successfully and crashes before marking the event as sent, it will publish that event again. The outbox therefore supports at-least-once delivery; consumers must deduplicate using a stable event or order ID. Ordering also requires an explicit design.

In Part 3, I will implement the Postgres outbox and a Rust relay. I will use LISTEN/NOTIFY to wake the relay when work arrives, with startup and reconnect scans plus periodic recovery checks for outstanding work.

Notifications are a signal to look for work. The outbox table is the durable record of that work.

Then I will carry the same order ID through delivery and matching, so replaying an outbox event cannot execute the order twice.

References

When Cheap isn't cheap anymore.

Suprie — Sun, 27 Sep 2026 10:53:24 +0000

During my time in my previous company, I've learned a lot, but here are two: (1) New APIs aren't always the right fit - diffable data source is great for partial updates, not full replacements. (2) 'Cheap' operations aren't cheap at scale - profile before you assume.

I've been tasked with handling real-time data using web sockets. On paper, the feature was easy. Instead of stopping at 10 price levels, show all of them - which could be anywhere between 80 to 137 price levels depending on the stock. During peak hours, the view that was responsive suddenly became frozen. Users couldn't scroll up and down, and unfortunately, this happened only during peak trading hours, so it slipped through QA.

I thought Diffable Data Source would fix it. I implemented it based on data associated with UUID, but it just made things worse. The issue is that the data sent isn't a snapshot of changes but the entire list of price levels. Diffing the entire list every time was pure overhead - no partial updates to optimize for. In this case, using tableView.reloadData() is faster.

Then I fired up the profiler to find the real bottleneck. Looking through the results, I was quite surprised. The computed properties - like color for up and down, and the number formatting - were clogging the main thread. The computations were cheap, but when hit with 30 packages per second, each carrying all price levels, they weren't cheap anymore. Even the localization we take for granted can clog up the main thread.

Before: 5 levels × 30 updates/sec × (formatting + color calc + localization) = manageable
After: 100 levels × 30 updates/sec × same operations = UI death

The solution is relatively straightforward: no more calculations on computed properties. All properties are calculated in background threads when converting the WebSocket response into view data. The view becomes dumb - it just reads values from the view data. After the changes, it managed to survive peak trading hours with smooth scrolling.

Now when we hit performance issues, we know where to look first.

Idempotency: Protecting User Intent Beyond the Buy Button

Suprie — Fri, 11 Sep 2026 09:03:36 +0000

User bought some stock but the network is slow. There is no immediate feedback, so out of frustration, they tap the Buy button several times. A few seconds later, multiple orders are matched.

Have you ever got into this situation?

Disabling the button in the UI helps, but it isn't guarantee. UI state changes happen on main thread and depend on when the run loops get a chance to process them. If the main thread is busy, multiple tap events may be handled before the UI visibly transitions into its disabled state.

And even when the UI behaves perfectly, relying on the client alone is dangerous. This is where idempotency comes in.

Idempotency

From Designing Data Intensive Applications:

An idempotent operation is one that you can perform multiple times, and it has the same effect as if you performed it only once.

In our case, what we actually want to protect is the user's intents. If the user intends to buy stock once, we don't want multiple taps, retries, or network issues to accidentally turn that into multiple orders.

But isn't that the backend jobs? Yes, but not entirely. The client needs a way to tell the server: "These requests represent the same intent", while the server needs a way to recognize that intent and ensure it is processed only once.

Idempotency is an end-to-end contract, not just a backend trick

So Who creates the idempotent key and when?

In our case, since we wanted to protect the user intent, it's on the client side. And since it's purpose to protect the user intent, I'm not recommend doing something like

func buy() async {
    let key = UUID()
}

This defeats the purpose. A key is created every time. Instead, I would do something along this:

struct OrderDTO {
    let idempotencyKey: UUID
    let symbol: String
    let side: Side
    let price: Decimal
    let lot: Int
}

@MainActor
@Observable
class OrderFormViewModel {
    var symbol = ""
    var price: Decimal = 0
    var lot: Int 
    var side: Side = .buy 

    private(set) var pendingOrder: OrderDTO?

    func submit() async throws {
        try validate()

        let order: OrderDTO
        if let pendingOrder {
            order = pendingOrder
        } else {
            let newOrder = createOrder()
            pendingOrder = newOrder
            order = newOrder
        } 

        do {
            let orderService = try await orderService.buy(order)
            pendingOrder = nil
        } catch {
            // retry using the pending order
            throw error
        }

    }

    private func createOrder() -> OrderDTO {
        OrderDTO(
            idempotencyKey: UUID(), 
            symbol: symbol, 
            price: price, 
            side: side,
            lot: lot
        )
    }
}

The important is not the UUID itself. It is when that UUID is created and how long we keep it. Once user submits the order, we create an order intent and assign idempotencyKey to it. Any retry with the same intent will reuse the same key.

So even if the user spams the buy button, it will create the order once and then send it to server. The key should only change when the user creates a new intent. For example, after the previous order has completed and they decided to create another one.

If you wanted to more orderly fashion instead of using UUID, which use UUID version 4, you can find some third pary library that generate UUID version 7 which include timestamp

But generating the key on the client is half of the contract. The server still needs to decide what to do when it receives the same key more than once. For example:

POST /order/submit
Idempotency-Key: 01DA...

POST /order/submit
Idempotency-Key: 01DA...

POST /order/submit
Idempotency-Key: 01DA...

The server should not treated them as three orders. Instead it can store the relationship between the idempotency key and the order being processed

01DA... -> Order #1234 -> Pending

When the request arrived with the same key, the server recognized that it has already seen this intent. Rather than creating another order, it can return the existing result:

{
  "order_id": "1234",
  "status": "pending"
}

And if the order has already completed:

{
  "order_id": "1234"
  "status": "matched"
  "payload": {
    ...
  }  
}

Now the responsibility is quite obvious:

The client declares the intent, and the server guarantees that the intent is not executed twice

And that is where things get more interesting on the backend: where do we store the key? How long should it live? What happens if two identical requests arrive at exactly the same time?

That's a topic for the next post.

The Sneaky Coordinator Leak in UIViewRepresentable

Suprie — Mon, 07 Sep 2026 23:36:02 +0000

Let's talk a little about a memory leak I recently found while working with UIViewRepresentable.
The issue happened in a custom UIKit view wrapped inside SwiftUI. At first, nothing looked suspicious. The view worked fine. But after navigating in and out of the screen a few times, the Memory Graph Debugger showed that the Coordinator instances kept increasing.
Here is a simplified version of the setup:

import SwiftUI
import UIKit

final class CallbackButton: UIButton {
    var onTap: (() -> Void)?
    override init(frame: CGRect) {
        super.init(frame: frame)
        addTarget(self, action: #selector(handleTap), for: .touchUpInside)
    }
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    @objc private func handleTap() {
        onTap?()
    }
    deinit {
        print("CallbackButton deinit")
    }
}

struct LeakyCallbackButtonView: UIViewRepresentable {

    @Binding var title: String
    func makeCoordinator() -> Coordinator {
        Coordinator(title: $title)
    }

    func makeUIView(context: Context) -> CallbackButton {
        let button = CallbackButton(type: .system)
        button.setTitle(title, for: .normal)
        // Looks harmless, but this strongly captures the coordinator.
        button.onTap = context.coordinator.handleTap
        return button
    }

    func updateUIView(_ uiView: CallbackButton, context: Context) {
        uiView.setTitle(title, for: .normal)
    }

    final class Coordinator {
        @Binding var title: String
        init(title: Binding<String>) {
            self._title = title
            print("Coordinator init")
        }
        func handleTap() {
            title = "Tapped at \(Date())"
        }
        deinit {
            print("Coordinator deinit")
        }
    }
}

The suspicious line is this one:

button.onTap = context.coordinator.handleTap

It looks like we are only passing a function, but an instance method reference still needs to retain its instance. In this case, the closure stored button.onTap strongly retains the Coordinator.
In a normal UIKit view controller, many people would immediately fix this with [weak self]. But this is UIViewRepresentable.

UIViewRepresentable is a struct, so self is a value type. You cannot use [weak self] the same way you would inside a UIViewController, because weak only applies to class-bound references.

The fix is to weakly capture the Coordinator instead:

struct FixedCallbackButtonView: UIViewRepresentable {
    @Binding var title: String

    func makeCoordinator() -> Coordinator {
        Coordinator(title: $title)
    }

    func makeUIView(context: Context) -> CallbackButton {
        let button = CallbackButton(type: .system)
        button.setTitle(title, for: .normal)
        button.onTap = { [weak coordinator = context.coordinator] in
            coordinator?.handleTap()
        }
        return button
    }

    func updateUIView(_ uiView: CallbackButton, context: Context) {
        uiView.setTitle(title, for: .normal)
    }

    static func dismantleUIView(_ uiView: CallbackButton, coordinator: Coordinator) {
        uiView.onTap = nil
    }

    final class Coordinator {
        @Binding var title: String
        init(title: Binding<String>) {
            self._title = title
            print("Coordinator init")
        }
        func handleTap() {
            title = "Tapped at \(Date())"
        }
        deinit {
            print("Coordinator deinit")
        }
    }
}

There are two fixes here:

button.onTap = { [weak coordinator = context.coordinator] in
    coordinator?.handleTap()
}

This prevents the closure from strongly retaining the Coordinator.
And:

static func dismantleUIView(_ uiView: CallbackButton, coordinator: Coordinator) {
    uiView.onTap = nil
}

This clears the callback when SwiftUI dismantles the UIKit view.
My takeaway:

// UIKit / UIViewController
{ [weak self] in
    self?.doSomething()
}

// UIViewRepresentable
{ [weak coordinator = context.coordinator] in
    coordinator?.doSomething()
}

UIViewRepresentable is a value-type wrapper, but the Coordinator is the reference object that usually carries UIKit-style lifetime and callback behavior. So when a UIKit view stores a closure, be careful not to accidentally retain the Coordinator through that closure.

Just a note for myself.

MVVM vs VIP, which one is the best?

Suprie — Thu, 03 Sep 2026 02:17:28 +0000

The short answer is neither.

There is no silver bullet; no single architecture can fit all codebases. And code, like requirements, is never fixed. It evolves alongside the codebase. What should not drift accidentally are boundaries.

For a greenfield project, I'd start with MVVM. Not because MVVM is inherently better than VIP, VIPER, or any other architecture, but because it's simple enough to start with, many developers are familiar with it, it works naturally with SwiftUI's state-driven model, and if done well, keeps the ViewModel focused on presentation state.

The mistake was thinking that an architecture's name will protect the codebase for you. It won't. A ViewModel can still become a dumping ground for network, persistence, and business rules. If infrastructure details leak into the Interactor or ViewModel, or dependencies are not hidden behind appropriate adapters, the code becomes harder to isolate, replace, and test.

Here's what a bad Interactor looks like:

class LoginInteractor: LoginBusinessLogic {
    let displayLogic: LoginDisplayLogic

    func doLogin(username: String, password: String) {
        Task {
            do {
                guard let url = URL(string: "https://api.example.com/login") else { return }
                var request = URLRequest(url: url)
                request.httpMethod = "POST"
                let (data, _) = try await URLSession.shared.data(for: request)
                let _ = try JSONDecoder().decode(LoginResult.self, from: data)
                displayLogic.showLoginSuccess()
            } catch {
                displayLogic.showLoginFailed(message: error.localizedDescription)
            }
        }
    }
}

struct LoginInteractorTest {

    @Test func testDoLogin() async throws {
        let displayLogic = FakeLoginDisplayLogic()
        let interactor = LoginInteractor(displayLogic: displayLogic)

        interactor.doLogin(username: "abc", password: "abc")

        // doLogin fires a Task internally — there's no way to await it from here.
        // We can't inject a fake result, so this test either:
        //   1. Hits the real endpoint with real credentials, or
        //   2. Races the network call and asserts before it even completes.
        try await Task.sleep(for: .seconds(2)) // guessing how long the network needs
        #expect(displayLogic.isLoggedIn == true) // flaky: fails if the network is slow
    }

}

Compare that to an Interactor that depends on an abstraction instead:

protocol LoginWorker {
    func doLogin(username: String, password: String) async throws -> LoginResult
}

class LoginInteractor: LoginBusinessLogic {
    let displayLogic: LoginDisplayLogic
    let worker: LoginWorker
    func doLogin(username: String, password: String) {
        Task {
            do {
                let _ = try await worker.doLogin(username: username, password: password)
                displayLogic.showLoginSuccess()
            } catch {
                displayLogic.showLoginFailed(message: error.localizedDescription )
            }
        }
    }
}

struct LoginInteractorTest {

    @Test func testDoLogin() async throws {
        let displayLogic = FakeLoginDisplayLogic()
        // Now you can just mock the worker, make it throw any error like succeed,
        // ,failed, or timeout without need to wait for estimated time api call succeed
        // because it never happened
        let worker = FakeLoginWorker()
        let interactor = LoginInteractor(displayLogic: displayLogic, worker: worker)
        interactor.doLogin(username: "abc", password: "abc")

        #expect(displayLogic.isLoggedIn == true)
    }
}

The architecture name matters less than whether the boundaries are actually respected.

The goal was never to reach a specific architecture, the goal is always to make the code understandable as complexity grows.

Dependency direction still matters:

Presentation -> Application / Use Case -> Domain <- Data Infrastructure

That direction defines the boundaries. UI should not know how data is fetched. Business rules should not care whether the data comes from an API, cache, or local DB. Infrastructure should not dictate how the application works.

Those boundaries are more important than whether a type is called ViewModel, Presenter, Interactor, or UseCase. If developers repeatedly struggle to answer questions like:

Where does this behavior belong?
Why does changing this feature require touching unrelated code?
Why do I need to understand five layers to change one screen?
What else breaks if I change this?

Then the current architecture may no longer be doing its job. That's a signal to refactor — not because of hype, but because the existing structure is no longer helping the team reason about change.

For an existing codebase, I'd optimize for incremental boundary improvements rather than introducing a new architecture everywhere. Create seams and the Strangler Fig pattern. The goal is understanding the system, not adopting any particular architecture pattern. Refactoring an existing codebase without understanding it first is like entering the battlefield without joining the briefing. You might know how to fight, but you don't yet know the objective, the terrain, the constraints, or why the current position exists.

Ugly code sometimes contains important business knowledge, or a workaround from a production incident years ago. Duplication may be accidental, or it may represent behavior that diverged for a reason. Before replacing the architecture, understand the system.

For a legacy codebase, the process is closer to:

Understand -> Test -> Find seam -> Replace -> Reassess

rather than

Choose architecture -> Rewrite

Testability is another important part of this. Architectures like MVVM and VIP often trade some delivery speed for clearer responsibilities, predictability, and easier testing. But testability only matters if you actually make use of it. Architecture can tell you where responsibilities belong. Tests tell you what the system is expected to do. That distinction becomes critical over time. Three months after a feature ships, someone will start wondering: "Is this intentional, or a bug?" A good dependency graph can't answer that, but more often than not, a good test can.

Consistency helps make reviews, debugging, onboarding, and refactoring easier. But it's not the goal by itself. The goal is a system the team can understand and change safely.

The best architecture is not the one with the most rules. It's the lightest structure that preserves your system's boundaries, and still lets the team change the code with confidence.