What's this about?
dotey's rule, stated in one line: split modules by *what will change*, not by *what happens first*. The common beginner mistake is dividing along the process — for an e-commerce checkout, one module per step: receive request, calculate price, charge, persist, send email. It works, and it makes every future change spread along the whole chain. Add an estimated delivery time and you touch all four steps, and missing one breaks it.
What is the alternative rule?
List what is most likely to change, then give each of those its own module with its implementation hidden behind an interface. For a shop: payment channels (Alipay today, WeChat tomorrow, Stripe when you go international), promotion rules (operations changes them constantly), notification methods (email, SMS, push), and where data is stored. Each becomes a module, and a change touches one place. This is information hiding, from Parnas's 1972 paper, and it remains the single most useful module-decomposition rule anyone has written down.
Why does this matter to you?
- His framing for the AI era: whether or not AI writes the code, module boundaries and coupling determine how well it can keep working in your codebase — and getting them right makes generated code better.
- Most experienced programmers do this by instinct and cannot articulate why, which is exactly why the one-line version is valuable.
- It pairs with Domain-Driven Agents from this week's HN — the same rule applied to agents instead of modules.