46 lines
1.8 KiB
Markdown
46 lines
1.8 KiB
Markdown
|
# Architecture and System Design
|
||
|
|
|
||
|
|
## Purpose
|
||
|
|
|
||
|
|
Shape meaningful technical direction so systems stay understandable, evolvable, and aligned with product needs over time.
|
||
|
|
|
||
|
|
## When to use
|
||
|
|
|
||
|
|
- Designing a major feature or subsystem
|
||
|
|
- Changing service boundaries, module boundaries, or core data flow
|
||
|
|
- Evaluating multiple implementation approaches with long-term consequences
|
||
|
|
- Preparing work that will influence maintainability, scale, or team velocity
|
||
|
|
|
||
|
|
## Inputs to gather
|
||
|
|
|
||
|
|
- Current architecture, boundaries, and pain points
|
||
|
|
- Product goals, scale expectations, and reliability constraints
|
||
|
|
- Existing patterns, platform constraints, and team operating model
|
||
|
|
- Compatibility, migration, and rollout concerns
|
||
|
|
|
||
|
|
## How to work
|
||
|
|
|
||
|
|
- Start from the user or system outcome, then identify the simplest architecture that supports it well.
|
||
|
|
- Make tradeoffs explicit: complexity, performance, reliability, maintainability, and delivery speed.
|
||
|
|
- Preserve useful existing boundaries unless there is a clear reason to change them.
|
||
|
|
- Prefer designs that are easy to operate and easy for the team to understand.
|
||
|
|
- Document why the chosen path is better than the main alternatives.
|
||
|
|
|
||
|
|
## Output expectations
|
||
|
|
|
||
|
|
- Clear recommended design or architecture direction
|
||
|
|
- Explicit tradeoffs and constraints
|
||
|
|
- Interfaces, boundaries, and rollout considerations that matter for implementation
|
||
|
|
|
||
|
|
## Quality checklist
|
||
|
|
|
||
|
|
- The design solves the actual problem, not a hypothetical future one.
|
||
|
|
- Tradeoffs are named clearly enough to guide later decisions.
|
||
|
|
- Complexity is justified by concrete needs.
|
||
|
|
- Operational and migration consequences are not ignored.
|
||
|
|
|
||
|
|
## Handoff notes
|
||
|
|
|
||
|
|
- Pair with architecture decision records when the choice should be preserved for future contributors.
|
||
|
|
- Call out which parts are decided versus intentionally deferred.
|