abd-architecture-blueprint
abd-architecture-blueprint
Purpose
The outline shows what a system is; the blueprint shows what it is made of. A blueprint is the document a tech lead opens to answer "where does the order code live? what does it depend on? how does it talk to the catalogue?" without yet drilling into the implementation patterns. It names every architectural component in a paragraph or two, catalogues every cross-cutting concern as an architecture mechanism, shows the data architecture at the model level, captures the common testing strategy, and lists the decisions taken at this level. When the blueprint is in place, the architecture reference can go deep on one mechanism at a time without re-explaining the system to its reader.
When to use this skill
Load this skill when any of the following apply:
- An architecture outline exists and the team now needs the next level of detail — what components exist, what each one is responsible for, how they relate.
- New engineers can read the outline but still cannot find the error-handling mechanism, the auth pattern, or the logging contract without asking — those belong in the blueprint as mechanisms.
- Code review keeps catching violations of cross-cutting concerns (errors thrown across the API boundary, logs that leak PII, validation duplicated in three places) — a named mechanism in the blueprint pulls the rule into the document.
- A data model question keeps coming up (where is the canonical Order, can the Catalogue write to the Identity store) — the blueprint's data-architecture section settles it.
- An architecture review is approaching and the outline is not enough — reviewers need component-level and mechanism-level material to do their job.
What is an architecture blueprint?
An architecture blueprint is the system-level reference that sits between the one-page outline and the deep-dive mechanism reference. It is organised around components (1–2 paragraphs each: purpose, dependencies, interactions — no internal structure detail), architecture mechanisms (each cross-cutting concern named and described in 1–2 paragraphs as a typed mechanism: Security, Error Handling, Logging, Validation, Configuration, Resilience, etc.), data architecture (domain model overview, entity relationships, persistence strategy), testing architecture (only the strategy common across components), and decision records for blueprint-level choices.