Video lesson: Module Boundaries Should Follow Change

Lesson promise

By the end, the learner should be able to explain the core model for module boundaries should follow change, apply it to a concrete input, and identify when its usual shortcut or guarantee stops applying. This is a recording brief; publish it as a playable lesson after the narration and visual sequence have been produced and reviewed.

Narration draft

A module groups decisions that are likely to change together and hides details other modules do not need. A useful boundary reduces the number of places that must change for one product decision. The public interface should express stable intent rather than expose internal storage or control flow.

If billing and email share a database table but change for different reasons, each may be better represented by its own module even when both run in one process. A narrow interface can let the implementation change from a local adapter to a remote service without rewriting every caller.

More modules do not automatically mean less complexity: excessive fragmentation adds indirection and coordination cost. A boundary drawn around technical layers may still couple unrelated product rules. Strong boundaries usually emerge from repeated change patterns and explicit ownership.

Visual sequence

1. Put the input and assumptions on screen. Ask the learner to predict the next state before revealing it.
2. Animate the representation and show the operation one transition at a time.
3. Pause at the boundary case in the companion article and compare the result with the invariant.
4. End with the exercise prompt: Choose a boundary for a feature that sends a receipt after a purchase. Decide which module owns payment state, receipt formatting, and delivery retries, and explain how dependencies flow.

Companion material

Use the article, trace, and interactive concept flow as the learner’s written and visual references. The video remains planned until an actual playable media URL and reviewed transcript are available.