2nd/10_Wiki/Topic_Programming/Architecture/소프트웨어 아키텍처 설계.md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-소프트웨어-아키텍처-설계	소프트웨어 아키텍처 설계	10_Wiki/Topics	verified	self	Software Architecture Design SW Architecture	none	A	0.9	applied	architecture design software-engineering		2026-05-10	pending	language framework agnostic agnostic

소프트웨어 아키텍처 설계

매 한 줄

"매 architecture는 매 의사결정의 기록이며, 매 변경 비용을 결정한다". Bass/Clements/Kazman의 SEI 정의 이후, 매 architecture는 매 코드 자체가 아닌 매 component / connector / constraint의 집합으로 본다. 매 2026 modern view는 매 evolutionary architecture (Ford) — 매 fitness function 으로 매 architectural property 를 매 자동 검증.

매 핵심

매 4+1 View (Kruchten)

• Logical: 매 도메인 객체 / 책임 분배.
• Process: 매 runtime concurrency / 매 thread / 매 process.
• Development: 매 module / 매 package 구조.
• Physical: 매 deployment topology.
• Scenarios (+1): 매 use case driven validation.

매 Quality Attributes (ISO/IEC 25010)

• Performance: latency, throughput.
• Scalability: horizontal / vertical 확장.
• Availability: SLA, MTBF, MTTR.
• Security: CIA triad.
• Modifiability: 매 변경 cost.
• Testability: 매 격리 가능성.

매 응용

1. C4 model 으로 매 stakeholder communication.
2. ADR (Architecture Decision Record) 으로 매 결정 추적.
3. Fitness function 으로 매 architectural drift 방지.

💻 패턴

ADR template

# ADR 0042: Adopt CQRS for Order service

## Status
Accepted (2026-05-10)

## Context
Read traffic 100x higher than write. Single Postgres table contention.

## Decision
Split into command (Postgres) + query (Read replica + Redis cache).
Event sourcing via Kafka.

## Consequences
+ Read scales independently.
- Eventual consistency window ~50ms.
- Two data models to maintain.

Fitness function (ArchUnit, Java)

@AnalyzeClasses(packages = "com.shop")
class ArchitectureTest {
    @ArchTest
    static final ArchRule domain_independent =
        noClasses().that().resideInAPackage("..domain..")
            .should().dependOnClassesThat().resideInAPackage("..infra..");

    @ArchTest
    static final ArchRule controllers_only_call_services =
        classes().that().resideInAPackage("..controller..")
            .should().onlyDependOnClassesThat()
            .resideInAnyPackage("..service..", "java..");
}

C4 Container diagram (Structurizr DSL)

workspace {
    model {
        user = person "Customer"
        shop = softwareSystem "Shop" {
            web = container "Web App" "React" "TypeScript"
            api = container "API" "Spring Boot"
            db = container "Database" "PostgreSQL 16"
        }
        user -> web "Browses"
        web -> api "Calls" "REST/JSON"
        api -> db "Reads/writes" "JDBC"
    }
}

Hexagonal Architecture (Python)

# domain/order.py — pure
class Order:
    def confirm(self) -> "Order": ...

# application/ports.py
class OrderRepo(Protocol):
    def save(self, o: Order) -> None: ...

# infra/postgres_order_repo.py — adapter
class PostgresOrderRepo:
    def save(self, o: Order) -> None:
        self.conn.execute("INSERT ...")

Event Storming output → bounded contexts

[Order Placed] → [Payment Authorized] → [Inventory Reserved] → [Order Confirmed]
   Order BC          Payment BC             Inventory BC           Order BC

매 결정 기준

상황	Approach
매 small team, simple domain	Modular monolith (Shopify-style)
매 high read/write asymmetry	CQRS
매 audit critical	Event sourcing
매 polyglot / independent scaling	Microservices
매 latency critical, ML inference	Service mesh + sidecar

기본값: 매 modular monolith → 매 evidence 기반 매 split.

🔗 Graph

• 부모: 아키텍처 패턴 지식
• 변형: Hexagonal Architecture · CQRS · Event Sourcing
• 응용: Microservices · Cloud_Native
• Adjacent: Domain-Driven Design · ADR · C4 Model (Architecture Documentation)

🤖 LLM 활용

언제: 매 ADR 초안 / 매 trade-off 분석 / 매 quality attribute scenario 생성. 언제 X: 매 production-grade fitness function 의 자동 작성 — 매 human review 필수.

❌ 안티패턴

• Big design up-front: 매 evolution 무시.
• Architecture astronaut: 매 abstraction layer 과잉.
• Distributed monolith: 매 microservice 의 분리 but 매 coupling 유지.
• No fitness function: 매 drift 매 silently.

🧪 검증 / 중복

• Verified (Bass/Clements/Kazman, Software Architecture in Practice 4e; Ford, Building Evolutionary Architectures 2e).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — 매 4+1, ADR, fitness function 패턴 추가