Antigravity Agent
45 lines
3.3 KiB
Markdown
45 lines
3.3 KiB
Markdown
---
|
|
id: P-REINFORCE-WIKI-ARCH-BOUNDED-CONTEXT
|
|
title: "제한된 컨텍스트 (Bounded Context)"
|
|
category: Dev
|
|
status: verified
|
|
canonical_id: ""
|
|
aliases: ["바운디드 컨텍스트", "Bounded Context", "도메인 경계", "모듈 분할"]
|
|
duplicate_of: ""
|
|
source_trust_level: A
|
|
confidence_score: 1.0
|
|
tags: ["DDD", "Architecture", "Strategic_Design", "Microservices", "Modularity"]
|
|
raw_sources: ["Datacollector_Export_2026-05-02"]
|
|
last_reinforced: 2026-05-02
|
|
github_commit: ""
|
|
---
|
|
|
|
# [[제한된 컨텍스트 (Bounded Context)]]
|
|
|
|
## 1. 개요
|
|
Bounded Context(제한된 컨텍스트)는 도메인 주도 설계(DDD)의 전략적 설계(Strategic Design)에서 가장 핵심적인 개념으로, 특정 모델과 용어(Ubiquitous Language)가 온전하게 의미를 유지하며 적용되는 논리적인 경계를 의미한다. 대규모 시스템을 관리 가능한 독립적인 단위로 분해하고, 팀 간의 명확한 책임 경계를 긋는 나침반 역할을 한다.
|
|
|
|
## 2. 핵심 원리
|
|
- **언어의 일관성**: 같은 '사용자(User)'라는 용어라도 결제 컨텍스트와 배송 컨텍스트에서는 서로 다른 속성과 행위를 가질 수 있다. Bounded Context는 이러한 언어의 다의성을 인정하고 경계 내에서의 일관성을 보장한다.
|
|
- **명확한 경계 (Explicit Boundary)**: 각 컨텍스트는 고유한 코드베이스, 데이터베이스, 팀 소유권을 가질 수 있으며, 외부 컨텍스트와의 통신은 정의된 인터페이스를 통해서만 이루어진다.
|
|
- **독립적 진화**: 경계가 명확히 분리되어 있으므로, 한 컨텍스트의 기술 스택 변경이나 내부 로직 리팩토링이 전체 시스템에 미치는 파급 효과를 최소화한다.
|
|
|
|
## 3. 실전 적용 및 가치
|
|
- **마이크로서비스의 기준**: Bounded Context는 마이크로서비스 아키텍처에서 개별 서비스의 경계를 정의하는 가장 신뢰할 수 있는 기준이 된다.
|
|
- **코드베이스 탐색**: 비즈니스 용어 중심으로 폴더와 모듈이 구성되므로, 개발자는 기술적 레이어(Controller, Service 등)가 아닌 비즈니스 도메인(Order, Inventory 등)을 따라 코드를 해독할 수 있다.
|
|
- **협업 최적화**: 팀별로 바운디드 컨텍스트를 할당함으로써 의사소통 비용을 줄이고 자율성을 부여한다.
|
|
|
|
## 4. 트레이드오프 및 주의사항
|
|
- **설계 복잡도**: 도메인에 대한 심층적인 분석이 선행되어야 하며, 경계를 잘못 설정할 경우 컨텍스트 간의 중복 데이터 관리나 통신 복잡성이 증가한다.
|
|
- **컨텍스트 매핑 (Context Mapping)**: 분리된 컨텍스트들이 서로 데이터를 주고받기 위해서는 공유 커널(Shared Kernel)이나 안티 코럽션 레이어(ACL) 같은 명시적인 관계 정의가 필수적이다.
|
|
|
|
## 5. 지식 연결 (Related)
|
|
- [[Domain_Driven_Design]]: Bounded Context를 포함하는 상위 설계 철학.
|
|
- [[Ubiquitous_Language]]: 컨텍스트 내부에서 사용하는 통용 언어.
|
|
- [[Microservices_Architecture]]: Bounded Context가 물리적으로 구현된 아키텍처 스타일.
|
|
|
|
## 🧪 검증 상태 (Validation)
|
|
- **정보 상태**: 검증 완료 (Verified)
|
|
- **출처 신뢰도**: A
|
|
- **검토 이유**: 대규모 시스템의 복잡성을 통제하고 독립적인 모듈화 성숙도를 높이기 위한 전략적 설계 표준 정립.
|