arch-identify

One-line summary

Diagnose which architecture style or cross-cutting pattern fits a stated problem — or route to a simpler DDD / design-pattern skill when an architecture-level answer is overkill.

When to use this skill

Greenfield system, picking a macro architecture style (monolith / microservices / event-driven / serverless).
Existing system facing scalability, integration, or transactional-consistency pressure and asking "what pattern fits".
Architecture-review framing: "should we have used X instead of Y".

When NOT to use this skill

Domain modeling question → route to ddd-design.
Code-level pattern question → route to gof-identify.
Kotlin-specific pattern question → route to kp-identify.

Core content

Walk the problem through these diagnostic questions, in this order:

1. Is this about the system's macro shape?

Default starting point, simple deployment, single codebase → arch-layered and stay with a monolith. Don't reach for microservices until the monolith has a real seam.
Decouple domain core from frameworks / databases / IO so each can change independently → arch-hexagonal (Ports & Adapters).
Loosely-coupled components communicating asynchronously through events → arch-event-driven.
Independent deployable units, each owning its data, communicating over a network → arch-microservices — but read the skill's "when NOT to" section first; it's the most over-applied style.

2. Is this about data, transactions, or consistency across services / aggregates?

Read load very different from write load; reads need denormalized views → arch-cqrs.
Source-of-truth is "what happened", not "current state"; full audit history; temporal queries → arch-event-sourcing. Pairs naturally with CQRS but doesn't require it.
A multi-step business transaction spans multiple services, no distributed transaction available → arch-saga.

3. Is this about failure handling between services?

Downstream service degrades or fails; calling service must protect itself and recover gracefully → arch-circuit-breaker (plus bulkhead and retry policies covered there).

4. Is this about evolving a legacy system?

Incremental migration from monolith to microservices, can't rewrite, must keep shipping → arch-strangler-fig. Often combined with an Anticorruption Layer (see ddd-context-mapping).

5. Is this about architecture quality and governance?

How do we know the architecture is staying healthy as the code evolves → arch-fitness-functions.
How do we record architectural decisions so future maintainers know why → arch-adr.
Component-level design discipline (single responsibility, dependency direction, etc.) → arch-solid.

6. None of the above?

The problem may not need an architecture-level answer. Most often: a DDD modeling decision (ddd-design), a code-level pattern (gof-identify), or "just don't overengineer this — keep the monolith".

Decision heuristics

Default to monolith first until you have a concrete reason to distribute.
Default to layered until you have a concrete reason to flip the dependency direction (which is what hexagonal does).
Distribution is a cost, not a feature. Microservices, sagas, event-driven, CQRS all add operational complexity. Justify them with specific requirements.
"We're building it that way because [respected company] does" is not a reason.

Anti-patterns

Picking microservices first and then trying to retrofit a domain model — leads to data-coupling and chatty services.
Adopting CQRS because "it sounds advanced" with no actual read/write asymmetry — pure overhead.
Reaching for sagas when a single transactional boundary would have done — the saga's compensating actions are real engineering cost.
"Resume-driven development" — picking an architecture for its career signal rather than fit.

References

Richards & Ford, Fundamentals of Software Architecture (O'Reilly, 2020) — Ch. 18, Choosing the Appropriate Architecture Style.
Khononov, Learning Domain-Driven Design (O'Reilly, 2021) — Ch. 14–15, DDD ↔ microservices ↔ event-driven.

About this skill