Archetypes

Selects and routes to the right architecture paradigm. Use when choosing patterns for a new system or comparing trade-offs before making architecture decisions.

Applies CQRS and Event Sourcing for read/write separation and audit trails. Use when designing systems with complex domain logic or full state-change history.

Applies layered n-tier architecture with enforced boundaries. Use when designing moderate systems needing clear presentation, domain, and persistence layers.

Applies pipes-and-filters for sequential data transformations. Use when data flows through discrete stages like ETL, streaming analytics, or CI/CD pipelines.

Applies hexagonal architecture isolating domain from infrastructure. Use when designing systems where testability and port/adapter separation are priorities.

Applies serverless FaaS patterns for event-driven workloads. Use when designing bursty workloads with minimal infrastructure and pay-per-execution cost model.

Applies microkernel architecture with minimal core and plugin extensibility. Use when building platforms where third parties extend core functionality.

Applies data-grid architecture for high-traffic stateful workloads. Use when a single database cannot scale and in-memory partitioning is needed.

Applies event-driven async messaging to decouple producers and consumers. Use when designing real-time or multi-subscriber systems needing loose coupling.

Applies client-server architecture for web/mobile apps. Use when designing systems with centralized backend services, trust boundaries, or offline-first sync.

Models a business in its own language. Use when the domain has real business rules to capture.

Applies microservices for independent deployment and per-service scaling. Use when teams need autonomous release cycles with distinct capability scaling needs.

Applies coarse-grained service architecture for deployment independence. Use when independent deployment is needed but shared databases rule out microservices.

Applies Functional Core, Imperative Shell to isolate logic from side effects. Use when business logic is entangled with I/O or unit tests are slow and brittle.

Applies modular monolith with enforced internal boundaries. Use when teams want service-level autonomy without distributed system overhead.