For Agents — Software Architecture Retrieval¶

Use this namespace as a software-architecture reasoning source, not as a menu of fashionable shapes.

Retrieval Loop¶

1. Clarify the design target: product surface, service, module, workflow, data system, integration boundary, or whole codebase.
2. Identify the current forces: latency, throughput, dependency churn, deployment boundaries, data ownership, team ownership, extensibility, testability, and migration risk.
3. Retrieve 3–8 relevant pages from software-architecture-metapatterns by pattern name, alias, force, or evolution path.
4. Compare candidates by:

• structural shape
• communication style
• dependency direction
• where business logic lives
• performance tradeoff
• operational/team cost
• possible next evolution

1. Produce a recommendation with citations to source pages and a small verification checklist.

Output Shape¶

Design target:
Observed forces:
Relevant metapatterns:
- Metapattern/source page: reason selected
Recommendation:
- preferred shape and why
Avoid:
- shapes that are overkill or mismatched
Evolution path:
- safe next step, rollback, and later split point
Verification checklist:
- concrete checks tied to dependency, performance, and ownership assumptions
License note:
- source is attributed external reference material; preserve provenance

Useful Starting Queries¶

• monolith layers services migration
• hexagonal architecture dependency inversion adapters
• orchestrator choreography saga event mediator
• pipeline throughput latency batch stream
• proxy gateway backend for frontend adapter
• polyglot persistence data ownership shared repository

Pixi/Jamie Use¶

• For codebase review: use this namespace to name the current shape before proposing changes.
• For product prototypes: prefer simple monolith/layers unless forces justify distribution.
• For agent work: cite the metapattern pages that shaped the plan so Pixoid can review the reasoning.
• For migration: retrieve the relevant evolution pages before recommending a split.