Architecture Documentation
Browse architecture documentation across Business, Solution, and Deployment views. Toggle roles and depth to see how L0–L2 perspectives connect.
Explore Architecture Documentation Layers
Max Level
BusinessSolutionDeploymentConceptConnectorL0–L3: depth of detailClick nodes to expand/collapseScroll/drag to zoom & panDouble‑click to refit
How To Design These Diagrams
A compact guide to the notation used across our architecture illustrations.
- Shapes: Use different silhouettes to signal what a thing is (for example, service, datastore, user). A given shape should map to one category only.
- Labels: Be explicit about what the text names — a capability, a product, or a specific technology. Only label items that benefit from clarification.
- Connectors: Arrows show direction. Vary line style to convey semantics: solid for synchronous calls, dashed for asynchronous or control, dotted for occasional/batch. A single line means one logical link unless annotated.
- Color: Color carries meaning, not decoration. Common encodings include lifecycle (current/planned), ownership, or licensing (OSS/commercial). Keep the palette consistent and define it in the legend.
- Layout: Position is informative. Left→right or top→bottom usually indicates flow from source to consumer. Boxes that span lanes represent cross‑cutting or shared capabilities.
- Icons: Treat icons as hints, not substitutes for names. If an icon implies a chosen product, pair it with the name and clarify whether it is implemented or merely an option.
- Legend: Every diagram should include a small key that decodes shapes, colors, and line styles, plus any important caveats directly on the figure.
- Glossary: Maintain a short glossary for recurring terms and abbreviations so meanings stay consistent across documents and teams.