DIGNALEGI
← All paths

Reading path · 3 pieces · About 33 min

Design boundaries that can evolve

Which early modeling choice will become expensive to change?

Move from the concepts a product elevates, to the attributes that genuinely belong together, to the public interface others depend on. This is a design discussion, not a prescription to split every system into services.

Who this is for: Technical product managers, founders and engineers who can follow a data model and an API example.

Take away: A boundary sketch with one coupling risk and one promise to downstream users.

Start reading ↓

Read in this order

Estimates use 250 words per minute, rounded up for each piece. Allow extra time for the reflection at the end. Open a piece for its selection note and available summary, then continue to the original.

  1. 01 / Name the central concept

    Your data model is your destiny ↗

    Matt Brown argues that the concepts a startup builds around shape its interface, pricing and expansion. Use the lens to examine a customer workflow, without treating database centrality as proof of product-market fit.

    Pause here: Is your central object how customers think, or how your first implementation happened to store things?

  2. 02 / Challenge accidental coupling

    Using anti-requirements to find system boundaries • Particular Software ↗

    Particular’s shopping-cart example uses deliberately implausible business rules to expose attributes that need not share a boundary. It also shows why domain experts must check the exceptions and why composition has a cost.

    Pause here: Which values change together, and which only happen to share a familiar noun?

  3. 03 / Respect the consumer’s contract

    Everything I know about good API design ↗

    A practical API-design essay explores compatibility, retries, pagination and operational limits. Read it for the costs an interface imposes on callers; its implementation preferences are opinions, not a complete security or transaction-safety specification.

    Pause here: Which change would look like a cleanup to you but break someone else’s working software?

How the pieces fit together

Brown uses data models as a strategic lens; his company examples are an investor’s interpretation, not a causal proof of why those companies succeeded. Particular narrows the discussion to a concrete shopping-cart model and the business rules behind its boundaries. The API essay adds the cost of exposing those choices to consumers. The useful tension is internal freedom versus external stability: decomposition can reduce coupling, but creates composition work and does not erase promises already made to users.

Digna Legi synthesis of the linked readings, not a claim that the authors endorse this combined approach.

Put five minutes aside

Put the idea to work

Use paper or your own notes app. These prompts are Digna Legi’s exercise, drawn from the readings.

  1. Name the central concept your customers work with, and compare it with what your product makes easiest to see and change.
  2. Choose two attributes currently grouped together. Ask a domain expert whether a business rule actually connects them; do not assume an absurd-sounding rule is impossible.
  3. Sketch a possible boundary and the information that still has to cross it. Include the cost of reconstructing the user’s view.
  4. Name an existing interface promise you must preserve and one failure or retry case its consumers need to handle. This is a review prompt, not a complete implementation design.

Before you leave: Which boundary will you sketch, what coupling might it remove, and which consumer promise must remain stable?