FP Algebra-Driven Design

FP Algebra-Driven Design

Algebraic thinking for API design. Discover the right API before implementing by specifying rules (equations) that operations must satisfy.

Cross-references: fp-principles | fp-domain-modeling | fp-usable-design

1. Why Algebraic Thinking

[STARTER]

Code is the wrong abstraction level for design. Starting with data structures inherits unnecessary constraints.

• Specify rules first, implement second. Implementation is a solution to a system of equations.
• Rules generate tests automatically. Every rule is directly a property test generating thousands of cases.
• Rules reveal missing features. Analysis often exposes operations you need but haven't designed.
• Rules catch contradictions early. Contradiction during design costs minutes; in production, days.

2. The Design Process

[STARTER]

1. Start with scope, not implementation. Don't decide data structures upfront.
2. Define observations first. How do users extract information? Observations define equality: two values equal if no observation distinguishes them. Gives enormous implementation freedom.
3. Add operations incrementally. For each new operation, immediately write rules connecting it to existing ones. This web of rules IS the design.
4. Let messy rules signal problems. Complex rules mean coarse building blocks. Decompose until each rule is nearly trivial.
5. Generalize aggressively. Remove unnecessary type constraints. If most operations don't inspect contained values, parameterize over them.

3. Common Algebraic Structures

[STARTER] -> [ADVANCED]

Recurring patterns in software. Recognizing them unlocks known rules and capabilities.

[STARTER] Combinable Values (Semigroup)