Start with the Boundary

When a design is still unclear, I try to draw its boundaries before I name its classes.

I write the parts, the information that crosses between them, and the decision each part owns. This small map often reveals the real difficulty. Two parts may both believe they own the same rule. A caller may need knowledge that should stay private. A “simple” module may actually be several responsibilities sharing one file.

The sketch does not need formal notation. Boxes, arrows, and a few questions are enough.

Starting here also improves later code review. The discussion can focus on ownership and data flow before it becomes attached to a particular implementation. Files matter, but they are the result of a design. The boundary is usually the better place to begin.