architecture-workflow

name	architecture-workflow
description	Use when designing a system from scratch, evaluating a monolith-to-MSA migration, or needing a structured end-to-end architecture process from domain discovery to documentation. Triggers on: "system architecture from scratch", "architecture
type	workflow
theme	architecture
scenarios	["Design a full architecture for our new e-commerce platform from domain events to ADRs","We need to evaluate whether to break our monolith into microservices — walk me through the process","Greenfield system design: take me from domain modeling through to architecture decisions","처음부터 아키텍처 전체 프로세스 진행해줘","모놀리스를 마이크로서비스로 전환할지 평가하고 설계까지 해줘","새 시스템 도메인 모델링부터 ADR 작성까지 단계별로 가보자"]
estimated_time	1-3 days (full), 2-6 hours per step
compatibility	{"recommended":["think-tool","sequential-thinking"],"optional":["mcp-reasoner"],"remote_mcp_note":"think-tool은 서비스 경계 결정, 아키텍처 트레이드오프 분석, ADR 작성에서 특히 유효합니다. sequential-thinking은 각 단계 간 컨텍스트를 유지하며 순서를 강제합니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요."}

Architecture Workflow

7-step process: domain discovery → modeling → boundary validation → layering → component design → distribution → documentation.

When to Use / When Not to Use

Use	Skip
New product or system from scratch	Single-skill task — use the individual skill directly
Monolith-to-MSA evaluation or system redesign	Iterating inside an existing stable architecture
Greenfield design needing structured decisions	Quick refactor within one service

---

Workflow Overview

[1] Event Storming          ← optional if domain is well-understood
        ↓
[2] Domain-Driven Design
        ↓
[3] Service Boundary Validator
        ↓
[4] Clean Architecture
        ↓
[5] Architecture Designer
        ↓
[6] Microservices Architect ← optional if staying on monolith
        ↓
[7] ADR Writer              ← always last

---

Steps

Step 1 — Event Storming

Skill: event-storming Goal: Discover bounded contexts, domain events, and aggregates through a structured workshop Input: Business domain description, stakeholder knowledge Output: Bounded context map, domain event timeline, aggregate candidates, hotspot list Skip if: Domain is well-modeled, ubiquitous language established, bounded contexts documented

"Step 1 시작" 또는 "이벤트 스토밍 워크샵 진행해줘"

---

Step 2 — Domain-Driven Design

Skill: domain-driven-design Goal: Formalize bounded contexts, aggregates, and ubiquitous language into a rigorous domain model Input: Bounded context candidates from Step 1 (or existing domain knowledge) Output: Context map, ubiquitous language glossary, aggregate definitions with invariants, domain event list Skip if: Full DDD model already exists and is validated by domain experts

"Step 2 시작" 또는 "DDD 도메인 모델링 해줘"

---

Step 3 — Service Boundary Validation

Skill: service-boundary-validator Goal: Validate proposed boundaries for coupling, data ownership conflicts, and distributed monolith patterns Input: Domain model and bounded contexts from Step 2 Output: Coupling analysis report, data ownership map, split/merge/keep recommendation per boundary Building a new monolith with no decomposition planned in the next 12 months