지금까지 경계의 개념을 배웠다. 이 장에서는 실제 시스템에서 경계를 어떻게 설정하는지 살펴본다.
Hunt the Wumpus
마틴은 Hunt the Wumpus라는 간단한 텍스트 기반 게임을 예로 든다.
| |
첫 번째 분석: 단순한 구조
flowchart LR
UI[UI] --> GR[Game Rules] --> DS[Data Storage]
단순해 보인다. 하지만 더 깊이 보면…
UI를 자세히 보기
UI를 자세히 분석하면 여러 경계가 보인다.
텍스트 전달 (Text Delivery)
메시지를 어떻게 전달할 것인가?
flowchart TB
subgraph Delivery [텍스트 전달 메커니즘]
CONSOLE[콘솔]
SMS[SMS]
WEB[웹]
end
GR[Game Rules] --> TD[Text Delivery Interface]
TD --> CONSOLE
TD --> SMS
TD --> WEB
언어 (Language)
어떤 언어로 표시할 것인가?
flowchart TB
subgraph Languages [지원 언어]
EN[English]
ES[Spanish]
KO[Korean]
end
TD[Text Delivery] --> LANG[Language Interface]
LANG --> EN
LANG --> ES
LANG --> KO
더 복잡한 구조
flowchart TB
subgraph UI [UI 레이어]
TD[Text Delivery]
LANG[Language]
subgraph Mechanisms [전달 메커니즘]
CONSOLE[Console]
SMS[SMS]
WEB[Web]
end
subgraph Translations [언어]
EN[English]
ES[Spanish]
KO[Korean]
end
end
subgraph Core [코어]
GR[Game Rules]
end
subgraph Storage [저장소]
DS[Data Storage]
subgraph Implementations [구현체]
MEM[Memory]
FILE[File]
CLOUD[Cloud]
end
end
CONSOLE --> TD
SMS --> TD
WEB --> TD
EN --> LANG
ES --> LANG
KO --> LANG
TD --> GR
LANG --> TD
GR --> DS
DS --> MEM
DS --> FILE
DS --> CLOUD
언어 경계
| |
전달 메커니즘 경계
| |
데이터 저장 경계
| |
경계가 어디에나
단순한 게임에서도 여러 경계가 존재한다:
flowchart TB
subgraph AllBoundaries [식별된 모든 경계]
B1[게임 규칙 ↔ UI]
B2[언어 ↔ 텍스트 전달]
B3[전달 메커니즘 ↔ 언어]
B4[게임 규칙 ↔ 데이터 저장]
B5[저장 구현 ↔ 저장 인터페이스]
end
| 경계 | 한쪽 | 다른 쪽 |
|---|---|---|
| UI 경계 | 게임 규칙 | 텍스트 전달 |
| 언어 경계 | 텍스트 전달 | 언어 구현 |
| 전달 경계 | 언어 | 전달 메커니즘 |
| 저장 경계 | 게임 규칙 | 데이터 저장 |
| 저장 구현 경계 | 저장 인터페이스 | 저장 구현체 |
경계를 얼마나 만들 것인가?
과도한 경계의 문제
flowchart LR
OVER[모든 경계 구현] --> COMPLEX[과도한 복잡성]
COMPLEX --> COST[높은 비용]
COST --> SLOW[개발 지연]
경계 부족의 문제
flowchart LR
UNDER[경계 없음] --> RIGID[유연성 부족]
RIGID --> CHANGE[변경 어려움]
CHANGE --> DEBT[기술 부채]
아키텍트의 결정
아키텍트는 다음을 수행해야 한다:
flowchart TB
A1[1. 가능한 경계 식별]
A2[2. 비용 대비 이익 분석]
A3[3. 현명한 결정]
A4[4. 지속적인 감시]
A1 --> A2 --> A3 --> A4
A4 -->|상황 변화| A1
결정 매트릭스
| 경계 | 변경 가능성 | 비용 | 결정 |
|---|---|---|---|
| 게임 규칙 ↔ UI | 높음 | 중간 | 구현 |
| 언어 지원 | 중간 | 낮음 | 구현 |
| 전달 메커니즘 | 낮음 | 중간 | 부분적 |
| 저장소 | 중간 | 중간 | 구현 |
| 저장 구현체 | 낮음 | 높음 | 지연 |
경계 설정 원칙
| |
핵심 요약
flowchart TB
subgraph Principles [경계 설정 원칙]
P1[미래를 예측하되 과도하지 않게]
P2[비용 대비 이익 분석]
P3[점진적으로 추가]
P4[지속적으로 재평가]
end
| 원칙 | 설명 |
|---|---|
| 식별 | 가능한 모든 경계 식별 |
| 분석 | 각 경계의 비용과 이익 분석 |
| 결정 | 현명하게 선택 |
| 감시 | 상황 변화에 따라 재평가 |
“아키텍트는 미래를 내다봐야 한다. 어디에 경계가 필요할지, 언제 필요할지 예측하고 비용을 고려해야 한다.” — Robert C. Martin
![Featured image of post [Clean Architecture] 35. 레이어와 경계](/post/cleanarchitecture/35-layers-and-boundaries-practical-setup/wordcloud_hu_47daf7ddd70df92d.png)
![[Clean Architecture] 33. 프레젠터와 험블 객체](/post/cleanarchitecture/33-presenter-humble-object-testability/wordcloud_hu_5e93c5ba5b0b8392.png)
![[Clean Architecture] 34. 부분적 경계](/post/cleanarchitecture/34-partial-boundaries-cost-benefit-balance/wordcloud_hu_466cf7f5f276e60b.png)
![[Clean Architecture] 35. 레이어와 경계](/post/cleanarchitecture/35-layers-and-boundaries-practical-setup/wordcloud_hu_cbbe4cbe47ba9693.png)
![[Clean Architecture] 36. 메인 컴포넌트](/post/cleanarchitecture/36-main-component-lowest-level-policy/wordcloud_hu_60ce8590c56aed0e.png)
![[Clean Architecture] 37. 서비스: 아키텍처 경계인가?](/post/cleanarchitecture/37-services-architecture-boundaries-microservices/wordcloud_hu_717de3c0940ae951.png)
![[Clean Architecture] 29. 정책과 수준](/post/cleanarchitecture/29-policy-and-level-high-level-dependency/wordcloud_hu_e48501593aac0e11.png)
![[Clean Architecture] 27. 경계: 선 긋기와 플러그인 아키텍처](/post/cleanarchitecture/27-boundaries-drawing-lines-plugin-architecture/wordcloud_hu_fc36676e3ba6ff35.png)
![[Clean Architecture] 26. 독립성: 유스케이스, 운영, 개발, 배포](/post/cleanarchitecture/26-independence-usecase-operation-development/wordcloud_hu_4f6373b2a6991347.png)
![[Clean Architecture] 22. 컴포넌트 응집도: REP, CCP, CRP](/post/cleanarchitecture/22-component-cohesion-rep-ccp-crp/wordcloud_hu_dc7d5d9e61ae2024.png)