A narrative level organizes code as a readable hierarchy: actions handle raw mechanics; scenes combine actions into one meaningful moment; chapters advance a coherent business goal; and a table of contents presents chapters in story order. Move upward by extracting meaningful methods that group closely related chunks, not by splitting code mechanically. section 2.3.4
Figure 2.2 Hierarchical structure of a story
The hierarchy shows how a table of contents contains chapters, chapters contain scenes and sometimes actions, and scenes contain actions. section 2.3.4
Choose a level by the responsibility the method should communicate:
- Use an action for one low-level operation, such as running a query, checking a condition, or sending a queue message. Keep it to one chunk, or at most two. section 2.3.4
- Use a scene for one dominant plot in a particular moment: prepare data, validate input, or handle a boundary crossing. It groups actions while keeping responsibility focused. section 2.3.4
- Use a chapter for multiple aligned scenes that express a broader business objective. A chapter can contain more than one plot when they serve one coherent goal. section 2.3.4
- Use a table of contents for the top-level ordering of chapters, giving the full story arc at a glance. section 2.3.4
From field check to registration story
An action-level validateMandatoryField checks whether a value is blank and throws a meaningful exception. A scene-level validateEmail first validates presence, then checks uniqueness. At the highest shown level, handleUserRegistration creates a pending user, sends a confirmation email, and records delivery failure, making the overall registration flow visible without exposing each low-level operation. section 2.3.4
Treat levels as a readability tool, not a quota. Extract when the caller would exceed its chunk budget, a group expresses a cohesive business concept, abstraction becomes more uniform, or a name reveals hidden intent. Keep code intact when it is already short, readable, and at one clear level; avoid extracting a body that contains only one simple chunk. section 2.5
A practical refactoring path is to identify recognizable chunks in a long method, extract low-level actions, group them into scenes, and reshape the original as a chapter. Then check that names clarify intent, central variables appear early, outcomes are explicit, and resources are cleaned up. This approach is especially useful for complex business logic and legacy code, but can be unnecessary for simple logic or quick prototypes. section 2.5
