30 lines
1.8 KiB
Markdown
30 lines
1.8 KiB
Markdown
# Design Synthesis
|
|
|
|
After discovery and before writing the design document, apply these three lenses to the collected findings. This step requires the full picture — do not parallelize.
|
|
|
|
## 1. Generalization
|
|
|
|
Look across all requirements as a group. Identify cases where multiple requirements are variations of the same underlying problem.
|
|
|
|
- If feature A is a special case of a more general capability X, design X with an interface that naturally supports A (and potentially B, C later)
|
|
- Keep the implementation scope to what the current requirements demand — generalize the interface, not the implementation
|
|
- Record identified generalizations in `research.md` under Design Decisions
|
|
|
|
## 2. Build vs. Adopt
|
|
|
|
For each major component in the emerging design, ask: is this problem already solved?
|
|
|
|
- Search for established standards (RFCs, protocols), battle-tested libraries, or platform-native capabilities that address the requirement
|
|
- Prefer adopting existing solutions over building custom ones when they fit the requirements without significant adaptation
|
|
- If adopting: verify the solution is actively maintained, compatible with the project's stack (check steering), and meets non-functional requirements
|
|
- If building: document why existing solutions were rejected (capture in `research.md`)
|
|
|
|
## 3. Simplification
|
|
|
|
For each component and abstraction layer in the emerging design, ask: is this necessary?
|
|
|
|
- Remove components that exist "just in case" or for hypothetical future requirements not in the current spec
|
|
- Flatten unnecessary abstraction layers — if an interface has only one implementation with no foreseeable second, it may not need the indirection
|
|
- Prefer fewer, cohesive components over many fine-grained ones
|
|
- The right design is the smallest one that satisfies all requirements and remains extensible at the interface level
|