# Learn the architecture

Start with the decisions the platform must protect: who a Party is, which source
owns a Project, which memberships have been observed, and what evidence permits
an operation. Then follow those decisions through persistence and delivery.

## Learning path

1. [Strategic DDD](strategic-ddd.md): language, ownership and bounded contexts.
2. [Tactical DDD](tactical-ddd.md): entities, values, aggregates and invariants.
3. [Hexagonal architecture](hexagonal-architecture.md): ports, adaptors and composition.
4. [CQRS](cqrs.md): commands, queries and revision-aware views.
5. [Event-driven architecture](event-driven-architecture.md): facts, contracts and reactions.
6. [Consistency and delivery](consistency-and-delivery.md): transactions, receipts, outboxes and recovery.
7. [Event sourcing](event-sourcing.md): choosing the authoritative persistence model.
8. [Testing and exercises](testing-and-exercises.md): evidence for each architectural claim.

The theory is adapted from the multilingual architecture reference; see
[attribution and source revision](attribution.md). Code excerpts are extracted at
build time from this checkout. The examples use Party Governance and Project from
the reviewed `integration/current` baseline. They illustrate specific boundaries and preserve
the contexts' documented limitations.

For implementation rules, consult [DDD.md](../../../DDD.md),
[ARCHITECTURE.md](../../../ARCHITECTURE.md) and the owning context README.