sebastian-411/architecture-mastery

Orquesta domain-driven-design, hexagonal-architecture, clean-architecture, solid-principles y design-patterns como un solo criterio coherente para diseñar backends nuevos o auditar código existente. Úsala como punto de entrada cuando el usuario pida "diseña esto con DDD + Hexagonal + Clean + SOLID", pida una revisión de arquitectura general, o pregunte si su código está sobre-diseñado o mal diseñado. Esta skill decide primero si la complejidad se justifica, antes de aplicar cualquier patrón - evitar overengineering es el criterio, no una excepción.

Aplica o revisa Clean Architecture - la regla de dependencia (las capas internas no conocen las externas), Use Cases explícitos, y frameworks/DB relegados a los bordes. Úsala cuando el usuario pida estructurar capas de un backend, decidir qué va en cada capa, o auditar si el código de negocio depende de un framework o de la base de datos. Se solapa con hexagonal-architecture; úsalas juntas cuando el usuario pida "clean + hexagonal" y evita duplicar el mismo consejo dos veces.

Modela el dominio de negocio usando Domain-Driven Design - Entities, Value Objects, Aggregates, Bounded Contexts y lenguaje ubicuo. Úsala cuando el usuario pida modelar un dominio complejo, decidir si algo es Entity o Value Object, definir los límites de un Aggregate, separar un monolito en Bounded Contexts, o cuando el negocio tenga reglas e invariantes no triviales. NO la apliques a dominios simples tipo CRUD sin reglas de negocio reales - ahí un modelo anémico simple es preferible.

Criterio de UI/UX de alto nivel para landings y aplicativos. Úsala al diseñar o implementar páginas, landings interactivas con 3D y animaciones al scroll (Awwwards / Apple product page / trailer), o apps Next.js que deben sentirse simples y hermosas. Exige escena WebGL enganchada al scroll, reutilización de componentes, rendimiento, y Playwright de diseño. No la uses para cambios de API/dominio sin UI.

Diseña o revisa un backend usando Arquitectura Hexagonal (Ports & Adapters) - separar el dominio/aplicación de frameworks, DB, colas y HTTP mediante puertos e interfaces. Úsala cuando el usuario pida diseñar un servicio nuevo, aislar el dominio de un framework (NestJS, Spring, Express, Django, etc.), decidir dónde va una interfaz o un adapter, o revisar si una capa está filtrando detalles de infraestructura hacia el dominio. En un proyecto desde 0, NestJS hexagonal es el default de greenfield-defaults. NO la apliques si el proyecto es un script pequeño, un CRUD trivial o un prototipo desechable - primero evalúa si la complejidad la justifica.

Orquesta a los agentes story-writer, architecture-reviewer, planner, implementer, code-reviewer y test-engineer de este plugin como un único proceso de desarrollo adaptativo, igual que lo escalaría un staff engineer - más proceso (con story.md/plan.md en specs/ y checkpoints de aprobación humana) para un cambio grande y riesgoso, casi nada de proceso para un cambio trivial. Úsala cuando el usuario pida implementar una feature o fix "de punta a punta", diga algo como "hazlo como lo haría un staff engineer" o "quiero todo el proceso", o cuando el pedido claramente involucra diseñar + planear + escribir + revisar + testear en una sola tarea. No la uses para una pregunta puntual de arquitectura (usa architecture-review) o una revisión suelta de código ya escrito (invoca code-reviewer directo).