Skip to content

Module 07: Effect Boundaries and Resource Safety

Page Maps

graph LR
  family["Python Programming"]
  program["Python Functional Programming"]
  section["Effect Boundaries Resource Safety"]
  page["Module 07: Effect Boundaries and Resource Safety"]
  capstone["Capstone evidence"]

  family --> program --> section --> page
  page -.applies in.-> capstone
flowchart LR
  orient["Orient on the page map"] --> read["Read the main claim and examples"]
  read --> inspect["Inspect the related code, proof, or capstone surface"]
  inspect --> verify["Run or review the verification path"]
  verify --> apply["Apply the idea back to the module and capstone"]

Read the first diagram as a placement map: this page sits between the course promise, the lesson pages listed below, and the capstone surfaces that pressure-test the module. Read the second diagram as the study route for this page, so the diagrams point you toward the Lesson map, Exercises, and Closing criteria instead of acting like decoration.

Keep These Pages Open

Use these support surfaces while reading so effect boundaries remain architectural contracts instead of turning into scattered adapter folklore:

  • Mid-Course Map for the move from modelling into system pressure
  • Review Checklist for the engineering bar around boundaries
  • Topic Boundaries for the scope line around functional technique versus infrastructure design
  • Capstone Map for the boundaries, capabilities, and domain effect surfaces in FuncPipe

Carry this question into the module:

Where should effects begin so the core remains testable and the boundary remains obvious to another reviewer?

This module is where the course stops talking only about pure internals and starts asking how real systems touch files, clocks, databases, logs, and transactions without losing clarity. The emphasis is on explicit boundaries rather than wishful purity.

Most of this module is the required production track. One page, Effect Interfaces, is an optional comparison core: it explains the native IOPlan representation and compares it with external-library styles without changing the main Module 07 architecture route.

Learning outcomes

  • how ports and adapters keep the core insulated from infrastructure details
  • how capability protocols define what effectful code is allowed to do
  • how cleanup, idempotency, and transactions become design contracts
  • how to migrate an existing codebase without pretending it can be rewritten overnight

Lesson map

Exercises

  • Draw one boundary between pure logic and infrastructure, then name the port or capability that keeps it honest.
  • Review one cleanup or transaction path and explain where failure handling must live for the contract to remain explicit.
  • Pick one migration step and justify why it is incremental enough to ship without rewriting the whole system.

Capstone checkpoints

  • Inspect which interfaces define capabilities and which files provide concrete adapters.
  • Review how cleanup and retries are enforced instead of implied.
  • Compare the migration guidance with the current boundaries in FuncPipe.

Before moving on

You should be able to explain where the pure core ends, how effects are introduced, and why capability discipline matters before async coordination enters the picture. Use Refactoring Guide and compare against capstone/_history/worktrees/module-07 before moving forward.

Closing criteria

  • You can point to the exact boundary where infrastructure enters the system and explain why that boundary is narrow enough.
  • You can explain how idempotency, cleanup, and transaction handling are enforced rather than assumed.
  • You can judge whether a migration plan preserves the core contracts while reality is still messy.

Directory glossary

Use Glossary when you want the recurring language in this module kept stable while you move between lessons, exercises, and capstone checkpoints.