Four seams to cut along

A large story does not split anywhere; it splits along a seam — a line already present in the problem, where one story is really several. Four seams recur often enough to name. By workflow step cuts a multi-step flow into one slice per step. By business rule cuts a story that holds several rules into the base rule first, each refinement after. By happy and sad path cuts the success case from each failure case. By operation cuts a “manage” story into the actions it bundles — browse, add, edit, remove.

The four differ in where they cut, but they share one rule: each resulting slice is vertical and valuable — small enough for one rung, and still a whole story a role could be shown. A cut that yields a fragment a role cannot use is the wrong seam, however small the fragment; that direction is the next dive. Read the pattern, then read the slices, and check the last column: every slice says one rung.

The hero surveys all four seams; this view works one of them to the bottom — by happy and sad path, on the Portal’s enrol story. The happy path is the success case: a learner enrols and is in. Each sad path is a distinct failure the story must handle: enrolling twice, or enrolling in a course already full. The happy path ships first, as its own rung; each sad path is a later rung with its own acceptance, not a clause buried in the first.

Step through the slices the seam produces. Each one is a complete behaviour: it has a role, a trigger, and an outcome a role can be shown. Splitting this way keeps the first rung small and shippable, and turns every “but what about…” into a separate, estimable story rather than scope creep inside one.

On the Portal — the learning platform this course builds — two of the locked stories carry two of the seams. “Manage the whole catalogue” splits by operation into browse, add, edit, and remove a course: four slices, each one rung, each demoable. “Enrol in a course” splits by happy and sad path into enrol successfully versus block a double enrolment: two slices, each a whole behaviour with its own acceptance. The other two seams appear on the same domain — enrol → confirm → notify is a workflow-step split, and enrol-with-no-cap then enrol-with-a-seat-limit is a business-rule split.

Across all four, the slices rest on ids that are already minted: Portal.ID.generate/1 returns a typed id and Portal.ID.decode/1 reads its .type back, so no slice waits on another to define identifiers. The companion Functional Programming course teaches those internals; this course cuts the stories.

# Two locked Portal stories, two seams.

# "manage the whole catalogue"  → BY OPERATION → 4 slices, each one rung:
#   browse a course · add a course · edit a course · remove a course

# "enrol in a course"           → BY HAPPY / SAD PATH → the success case, then each failure:
#   enrol successfully  ·  block a double enrolment

id = Portal.ID.generate(:course)        # ids are already minted — no slice waits on another for identity
assert Portal.ID.decode(id).type == :course

The signal said the story is too big; the patterns say where it divides. Four seams recur: by operation, which splits a “manage” story into its actions; by happy and sad path, which splits a behaviour into success and each failure; by workflow step, which splits a flow into its steps; and by business rule, which splits a rule-set into the base rule and its refinements. Each seam is chosen so every slice stays vertical and valuable — small enough for one rung, still a story a role can be shown. With the seams in hand, one question remains: which direction must the cut run.

The story-splitting patterns this dive draws on, and where they connect in the course.