Refactor: Consolidate directory structure into 5 main categories and update metadata

10_Wiki/Topics_Dev/Bounded_Context.md

@@ -1,45 +1,44 @@
 ---
-id: P-REINFORCE-WIKI-DEV-BOUNDED-CONTEXT
-title: "바운디드 컨텍스트와 도메인 모델 경계 (Bounded Context)"
-category: "10_Wiki/💻 Topics_Dev"
+id: P-REINFORCE-WIKI-ARCH-BOUNDED-CONTEXT
+title: "제한된 컨텍스트 (Bounded Context)"
+category: Dev
 status: verified
 canonical_id: ""
-aliases: ["Bounded Context", "바운디드 컨텍스트", "도메인 경계", "서브도메인", "언어의 경계"]
+aliases: ["바운디드 컨텍스트", "Bounded Context", "도메인 경계", "모듈 분할"]
 duplicate_of: ""
 source_trust_level: A
 confidence_score: 1.0
-tags: ["DDD", "Architecture", "Modularity", "Ubiquitous_Language", "System_Design"]
+tags: ["DDD", "Architecture", "Strategic_Design", "Microservices", "Modularity"]
 raw_sources: ["Datacollector_Export_2026-05-02"]
 last_reinforced: 2026-05-02
 github_commit: ""
 ---
 
-# [[바운디드 컨텍스트와 도메인 모델 경계 (Bounded Context)]]
+# [[제한된 컨텍스트 (Bounded Context)]]
 
 ## 1. 개요
-바운디드 컨텍스트(Bounded Context)는 도메인 주도 설계(DDD)의 핵심 개념으로, 거대하고 복잡한 비즈니스 도메인을 논리적으로 일관된 작은 하위 시스템으로 분할하는 설계 패턴이다. 각 컨텍스트는 고유한 모델과 유비쿼터스 언어(Ubiquitous Language)가 통용되는 명확한 경계(Boundary)를 가지며, 이를 통해 시스템 내의 용어 충돌을 방지하고 모듈 간의 자율성을 극대화한다.
+Bounded Context(제한된 컨텍스트)는 도메인 주도 설계(DDD)의 전략적 설계(Strategic Design)에서 가장 핵심적인 개념으로, 특정 모델과 용어(Ubiquitous Language)가 온전하게 의미를 유지하며 적용되는 논리적인 경계를 의미한다. 대규모 시스템을 관리 가능한 독립적인 단위로 분해하고, 팀 간의 명확한 책임 경계를 긋는 나침반 역할을 한다.
 
-## 2. 핵심 메커니즘 및 특징
-- **언어의 경계**: 동일한 단어라도 컨텍스트에 따라 의미가 달라질 수 있다. 예를 들어, '상품'이라는 단어는 주문 컨텍스트에서는 '판매 대상'이지만, 배송 컨텍스트에서는 '무게와 부피를 가진 화물'로 해석된다. Bounded Context는 이러한 의미적 경계를 명확히 긋는다.
-- **모델의 일관성**: 하나의 컨텍스트 내부에서는 모델이 모순 없이 일관되게 동작해야 한다. 경계 밖의 모델과는 느슨하게 결합하며, 필요한 데이터는 컨텍스트 매핑(Context Mapping)을 통해 교환한다.
-- **팀과 코드의 독립성**: Bounded Context는 팀 단위의 조직 구조와도 밀접하게 연관되며(Conway's Law), 각 컨텍스트별로 최적화된 기술 스택과 독립적인 배포 파이프라인을 가질 수 있는 기술적 토대가 된다.
+## 2. 핵심 원리
+- **언어의 일관성**: 같은 '사용자(User)'라는 용어라도 결제 컨텍스트와 배송 컨텍스트에서는 서로 다른 속성과 행위를 가질 수 있다. Bounded Context는 이러한 언어의 다의성을 인정하고 경계 내에서의 일관성을 보장한다.
+- **명확한 경계 (Explicit Boundary)**: 각 컨텍스트는 고유한 코드베이스, 데이터베이스, 팀 소유권을 가질 수 있으며, 외부 컨텍스트와의 통신은 정의된 인터페이스를 통해서만 이루어진다.
+- **독립적 진화**: 경계가 명확히 분리되어 있으므로, 한 컨텍스트의 기술 스택 변경이나 내부 로직 리팩토링이 전체 시스템에 미치는 파급 효과를 최소화한다.
 
-## 3. 엔지니어링 가치
-- **복잡성 제어**: 시스템 전체를 한꺼번에 이해하려 하지 않고, 특정 비즈니스 목적을 가진 컨텍스트 단위로 쪼개어 인지 부하를 획기적으로 줄임.
-- **마이크로서비스 분할 표준**: 모놀리식 시스템을 마이크로서비스로 전환할 때, 기술적인 계층이 아닌 비즈니스 가치 중심의 서비스 경계를 설정하는 가장 강력한 기준 제공.
-- **결함 격리 및 유연성**: 한 컨텍스트 내부의 모델 변경이 다른 컨텍스트에 영향을 미치지 않도록 방어막(Anti-Corruption Layer 등)을 형성하여 시스템의 지속적인 진화 지원.
+## 3. 실전 적용 및 가치
+- **마이크로서비스의 기준**: Bounded Context는 마이크로서비스 아키텍처에서 개별 서비스의 경계를 정의하는 가장 신뢰할 수 있는 기준이 된다.
+- **코드베이스 탐색**: 비즈니스 용어 중심으로 폴더와 모듈이 구성되므로, 개발자는 기술적 레이어(Controller, Service 등)가 아닌 비즈니스 도메인(Order, Inventory 등)을 따라 코드를 해독할 수 있다.
+- **협업 최적화**: 팀별로 바운디드 컨텍스트를 할당함으로써 의사소통 비용을 줄이고 자율성을 부여한다.
 
 ## 4. 트레이드오프 및 주의사항
-- **설계 난이도 및 분석 비용**: 비즈니스 도메인에 대한 깊은 이해와 도메인 전문가와의 밀접한 협업이 필수적이며, 경계를 잘못 설정할 경우 컨텍스트 간 데이터 중복과 통신 오버헤드만 증가할 위험이 있음.
-- **통합의 복잡성**: 분리된 컨텍스트 간에 일관성을 유지하기 위해 이벤트 기반 통신이나 공유 커널(Shared Kernel) 등의 정교한 통합 전략 필요.
-- **오버엔지니어링 경계**: 단순한 도메인에서도 무리하게 컨텍스트를 쪼개는 것은 불필요한 추상화 오버헤드와 운영 비용만 발생시킬 수 있으므로 주의.
+- **설계 복잡도**: 도메인에 대한 심층적인 분석이 선행되어야 하며, 경계를 잘못 설정할 경우 컨텍스트 간의 중복 데이터 관리나 통신 복잡성이 증가한다.
+- **컨텍스트 매핑 (Context Mapping)**: 분리된 컨텍스트들이 서로 데이터를 주고받기 위해서는 공유 커널(Shared Kernel)이나 안티 코럽션 레이어(ACL) 같은 명시적인 관계 정의가 필수적이다.
 
 ## 5. 지식 연결 (Related)
-- [[Domain_Driven_Design]]: Bounded Context가 속한 상위 설계 방법론.
+- [[Domain_Driven_Design]]: Bounded Context를 포함하는 상위 설계 철학.
+- [[Ubiquitous_Language]]: 컨텍스트 내부에서 사용하는 통용 언어.
 - [[Microservices_Architecture]]: Bounded Context가 물리적으로 구현된 아키텍처 스타일.
-- [[Ubiquitous_Language]]: 각 컨텍스트 내부에서 사용하는 공통 언어 체계.
 
 ## 🧪 검증 상태 (Validation)
 - **정보 상태**: 검증 완료 (Verified)
 - **출처 신뢰도**: A
-- **검토 이유**: 대규모 시스템의 비즈니스 복잡성을 관리 가능한 단위로 분해하고, 기술 중심이 아닌 도메인 중심의 견고한 아키텍처를 구축하기 위한 설계 표준 정립.
+- **검토 이유**: 대규모 시스템의 복잡성을 통제하고 독립적인 모듈화 성숙도를 높이기 위한 전략적 설계 표준 정립.