Antigravity Agent
162 lines
5.1 KiB
Markdown
162 lines
5.1 KiB
Markdown
---
|
|
id: wiki-2026-0508-소프트웨어-아키텍처-설계
|
|
title: 소프트웨어 아키텍처 설계
|
|
category: 10_Wiki/Topics
|
|
status: verified
|
|
canonical_id: self
|
|
aliases: [Software Architecture Design, SW Architecture]
|
|
duplicate_of: none
|
|
source_trust_level: A
|
|
confidence_score: 0.9
|
|
verification_status: applied
|
|
tags: [architecture, design, software-engineering]
|
|
raw_sources: []
|
|
last_reinforced: 2026-05-10
|
|
github_commit: pending
|
|
tech_stack:
|
|
language: agnostic
|
|
framework: 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
|
|
```markdown
|
|
# 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)
|
|
```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)
|
|
```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]] · [[Modular Monolith]]
|
|
- Adjacent: [[Domain-Driven Design]] · [[ADR]] · [[C4 Model]]
|
|
|
|
## 🤖 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 패턴 추가 |
|