charlieviettq System Mapping
Lightweight system mapping before deep implementation or refactor. Produces diagrams and narrative that clarify boundaries and dependencies.
When to use
- Onboarding to unfamiliar codebase or pipeline
- Planning integration between services
- Explaining credit/ML/data flows to stakeholders
When not to use
- Formal ADR decision (use
architecture-decision-records) - Auto-generating code from diagram
Workflow
- Scope — system boundary; actors; in/out of scope
- Components — services, stores, queues, humans, external APIs
- Flows — primary happy path; note sync vs async
- Feedback — loops, retries, batch vs realtime
- Risks — single points of failure, PII paths, manual steps
- Diagram — Mermaid or C4-style; keep readable in markdown
Diagram tips
- Start context/container level; drill to component only where needed
- Label data classifications on flows with sensitive data
- Version diagram with date in doc title or footer
Output template
## System map: [name]
- **Purpose:**
- **Actors:**
- **Components:** (table: name, role, owner)
- **Primary flows:**
- **Diagram:** (mermaid block)
- **Open questions:**