See Archally in Action

What Was Modeled

PrestaShop v9 is a major open-source e-commerce platform with thousands of entities, services, and integration points. We modeled its full architecture as a structured blueprint — not a static diagram, but a living, queryable representation of the entire system.

What This Proves

At this scale (2000+ entities, 2000+ relations), traditional documentation breaks down. Diagrams become unreadable. Wikis go stale. Spreadsheets lose context.

The blueprint approach handles this complexity because the model is typed, versioned, and generates its own visualizations. When PrestaShop’s architecture changes between versions, the blueprint captures what moved, what broke, and what downstream systems are affected — automatically.

Key Capabilities Demonstrated

• Blueprint migrations: Track architectural changes between v8 and v9, with full diff and rationale
• Change impact analysis: Query which entities, APIs, and integrations are affected by a specific change
• Multi-view generation: One model produces dependency graphs, API specs, and integration maps — all consistent
• Scale handling: 2000+ entities navigable through filtered views, not one overwhelming diagram

What Was Modeled

The e-commerce reference blueprint captures the canonical bounded contexts of an online retail platform — product catalog, basket, checkout, fulfillment, customer accounts, and back-office operations. Each context is authored as typed YAML with explicit IDs and cross-references, then composed into a coherent multi-vertical model.

What This Proves

Composable modeling at e-commerce scale: bounded contexts compose without losing local autonomy. The blueprint emits OpenAPI contracts for the storefront, AsyncAPI contracts for the order-fulfillment event flow, ADRs for the major architecture decisions, and Event Storming views for stakeholder review — all from one source.

Try the Demo

Use the interactive studio above to browse entities, scrub through architecture chapters, and watch one YAML change regenerate the OpenAPI spec live.

What Was Modeled

A complete residential property — rooms, equipment, systems, maintenance schedules — captured as a structured model. From that single source, the system generates 2D floor plans, interactive 3D views, and a living maintenance calendar.

What This Proves

The blueprint approach is not limited to software architecture. Any domain with structured relationships and change over time benefits from the same principles: model once, generate many outputs, keep everything in sync.

A property model changes when equipment is replaced, rooms are renovated, or maintenance schedules shift. The generated views update automatically — no manual redrawing, no stale documentation.

Key Capabilities Demonstrated

• Cross-domain modeling: Architecture modeling principles applied to physical property, not just software
• Real-time visualization: 2D floor plans and 3D views generated directly from the model
• Maintenance calendar: Equipment lifecycle tracking with scheduled maintenance derived from model data
• Living documentation: When the property changes, all generated views reflect the current state

What Was Modeled

The biotech e-commerce blueprint extends the e-commerce reference with the operational realities of selling regulated biological materials online. Compliance entities, batch traceability, cold-chain shipping constraints, and audit-trail decisions are modeled as first-class typed entities — not bolted on as documentation.

What This Proves

Composition across verticals works in regulated domains: the same blueprint that emits OpenAPI contracts also emits the regulatory evidence trail that compliance teams need. Decisions (ADR) and business decisions (BCC v5 BD###) live next to the bounded contexts they govern, with evidence_refs linking each claim to its source.

Try the Demo

Use the interactive studio above to inspect the compliance plane, follow how a batch flows through cold-chain logistics, and see how a single ADR ripples through the impact-report MCP.