Decide where a system should split — what changes together stays together, and a boundary is a bet about future change. Use when adding a module, splitting a file that has grown, or reviewing a design that feels tangled.
--- name: choose-a-module-boundary category: coding description: >- Decide where a system should split — what changes together stays together, and a boundary is a bet about future change. Use when adding a module, splitting a file that has grown, or reviewing a design that feels tangled. --- # Choose a Module Boundary A module boundary is a bet: these things will change for different reasons, so they should be able to change without taking each other with them. Get the bet right and the next slice is a small commit. Get it wrong and every feature touches six files that all know about each other. The code will not tell you the right split. The change history will. What tends to change together belongs together. What you keep wishing you could swap independently wants a boundary. ## Start from change, not from nouns Nouns are a trap. `User`, `Order`, `Arrow` look like modules because they are things. They are usually *data that many behaviours share*, which is the opposite of a good boundary — split along those lines and every feature imports all three. Ask instead: - What will force a change here in the next six months? - What should be able to change *without* this changing? - If I had to replace this piece, what would I want to keep? A parser that changes when the file format changes, and a scorer that changes when the rules change, want a boundary even if they both touch "arrows." A `utils.py` that changes whenever anything changes is not a module, it is a drawer.
You are reading the opening of this skill.
The rest is open to any signed-in account — free included. Reading the library costs nothing.
Shared publicly by the author and open for any use. See the Terms.