Organizer 정리 산출물(From_RawData) + 이사 체크리스트 + 인덱스 갱신

- Raw_Data 자동 정리 산출물이 각 도메인 From_RawData/ 로 편입, 00_INDEX 연결 갱신
- 컴퓨터_이사_체크리스트.md 추가 (두뇌-상대 경로 규약 v2.2.304 — 새 컴퓨터에서
  바꿀 절대 경로는 localBrainPath 1개)
- Astra 세션 산출물(에피소드 기억·기능 인벤토리) 갱신

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

10_Wiki/Topics/Domain_Programming/From_RawData/도메인 주도 설계 (Domain-Driven Design).md

@@ -0,0 +1,96 @@
+```markdown
+---
+id: 도메인-주도-설계-(domain-driven-design)
+title: "도메인 주도 설계 (Domain-Driven Design)"
+category: "Architecture"
+status: "draft"
+verification_status: "conceptual"
+canonical_id: ""
+aliases: ["DDD", "Domain-Driven Design", "도메인 주도 개발", "도메인 주도 설계"]
+duplicate_of: ""
+source_trust_level: "B"
+confidence_score: 0.90
+created_at: 2026-07-11
+updated_at: 2026-07-11
+review_reason: ""
+merge_history: []
+tags: ["research", "풀이 과정이 담긴 워크드 예제 (worked examples)"]
+raw_sources: ["인지 부하가 중요합니다 ("Cognitive load is what matters" 원문) - velog"]
+applied_in: []
+github_commit: ""
+---
+
+# [[도메인 주도 설계 (Domain-Driven Design)]]
+
+## 🎯 한 줄 통찰 (One-line insight)
+도메인 주도 설계(DDD)는 '해결 방법(Solution Space)'이 아닌 '문제 영역(Problem Space)'에 대한 접근 방식이며, 이를 코드 구현 템플릿으로 오해하여 적용할 경우 주관적 해석의 난립으로 인해 미래의 개발자에게 심각한 외재적 인지 부하(Extraneous Cognitive Load)를 유발한다.
+
+## 🧠 핵심 개념 (Core concepts)
+* **문제 영역(Problem Space) 지향:** 유비쿼터스 언어, 도메인, 경계 컨텍스트(Bounded Context), 집계(Aggregate), 이벤트 스토밍 등은 문제 영역에 관한 개념들로, 도메인에 대한 통찰력을 얻고 경계를 추출하기 위해 고안되었다.
+* **통일된 의사소통의 도구:** 개발자, 도메인 전문가 및 비즈니스 담당자가 단일하고 통일된 언어를 사용하여 효과적으로 의사소통할 수 있도록 지원하는 프레임워크다.
+* **해결 방법(Solution Space)으로의 오해:** DDD를 특정 폴더 구조, 서비스, 리포지토리 계층 등의 구체적 소프트웨어 구현 및 아키텍처 기술로 착각하고 남용하는 경향이 존재한다.
+* **주관적 멘탈 모델과 인지 과부하:** DDD에 대한 해석은 개인마다 독특하고 주관적이어서, 이를 바탕으로 코드를 설계하면 코드를 읽는 독자마다 다른 멘탈 모델을 요구하게 되어 막대한 외재적 인지 부하를 야기한다.
+
+## 🧩 추출된 패턴 (Extracted patterns)
+* **해결 방법 공간으로의 오용 안티 패턴 (Misuse in Solution Space):** "우리는 DDD 방식으로 코드를 짠다"는 명목하에 복잡한 추상화, 리포지토리 패턴, 폴더 구조를 강제하는 행위. 이는 시스템에 대한 공통 기반을 형성하기보다 10명의 개발자에게 10개의 다른 멘탈 모델을 강요하게 되어 불필요한 논쟁과 🤯인지 과부하를 초래한다.
+
+## ⚖️ 비교 및 선택 기준 (Comparison & decision criteria)
+
+| 항목 (Option) | 장점 | 단점 | 언제 선택 |
+|---|---|---|---|
+| **도메인 주도 설계 (DDD)** | 개발자와 도메인 전문가, 비즈니스 담당자 간 단일하고 통일된 언어(유비쿼터스 언어)를 사용하여 의사소통과 도메인 경계 추출에 매우 효과적임 | 해석이 주관적이고 다양하여 코드 구조(Solution Space)에 무리하게 적용 시 외재적 인지 부하가 급증하고 논쟁의 장이 됨 | 복잡한 비즈니스 문제 영역(Problem space)을 분석하고 이해관계자 간 의사소통 구조를 통일할 때 |
+| **팀 토폴로지 (Team Topologies)** | 팀 전체에 걸쳐 인지 부하를 분산시키는 데 효과적이며, 엔지니어들이 비교적 일관되고 유사한 멘탈 모델을 형성하게 됨 | 소스에 관련 정보가 부족합니다. | 조직 내 인지 부하를 합리적으로 분산하고 일관된 팀 구조와 이해를 갖추고자 할 때 |
+
+## 📖 세부 내용 (Details)
+* **DDD의 본질적 목적:** 도메인 주도 설계(DDD)는 훌륭한 개념을 많이 포함하고 있지만 실무에서는 종종 크게 오해받는다. 가장 흔한 오해는 "우리는 DDD 방식으로 코드를 짠다"고 말하는 것인데, 본래 DDD는 '해결 방법(solution space)'을 위한 코드 템플릿이 아니라 '문제 영역(problem space)'을 탐구하고 구조화하기 위한 접근 방식이기 때문이다 [S1].
+* **의사소통 도구로서의 가치:** 유비쿼터스 언어, 도메인, 경계 컨텍스트, 집계, 이벤트 스토밍 등의 기법들은 철저하게 문제 영역을 분석하기 위한 도구다. 이들은 도메인의 통찰력을 습득하고 논리적 경계를 추출함으로써, 개발자, 도메인 전문가, 비즈니스 부서가 단일하고 통일된 언어로 소통할 수 있게 돕는다 [S1].
+* **솔루션 공간에서의 남용과 인지 부하의 폭증:** DDD를 특정 폴더 구조, 서비스 설계, 리포지토리 패턴 등과 같은 '해결 방법' 기술로 지나치게 강조하고 코드베이스에 직접 투영하는 경향이 빈번하게 발생한다 [S1]. 문제는 각 개발자가 DDD를 해석하는 방식이 주관적이고 다양하다는 점이다. 이러한 개인적 이해를 바탕으로 코드를 억지로 구조화하면, 코드를 읽는 10명의 사람에게 10개의 완전히 다른 멘탈 모델을 요구하게 된다. 결과적으로 이는 공통의 기술적 기반이 되기는커녕 불필요한 논쟁을 유발하며, 시스템을 이해하려는 미래의 개발자에게 치명적인 수준의 외재적 인지 부하를 부과하여 프로젝트를 파멸로 이끌 수 있다 [S1].
+
+## ⚖️ 모순 및 업데이트 (Contradictions & updates)
+일반적인 소프트웨어 엔지니어링 업계 상식에서는 DDD를 복잡한 비즈니스 애플리케이션을 구축하는 강력한 아키텍처 및 구현 방법론으로 장려하지만, 소스 문헌에서는 이를 '코드 해결 방법(Solution Space)'에 억지로 끼워 맞추는 행위가 오히려 막대한 외재적 인지 부하를 초래하는 안티 패턴이라고 정면으로 비판하며, DDD의 활용을 철저하게 '문제 영역(Problem Space)' 내의 의사소통 수단으로 제한할 것을 시사하고 있다.
+
+## 🛠️ 적용 사례 (Applied in summary)
+현재 발견된 실제 적용 사례가 없습니다.
+
+## 💻 코드 패턴 (Code patterns)
+소스에 코드 예시 없음.
+
+## ✅ 검증 상태 및 신뢰도
+- **상태:** draft
+- **검증 단계:** conceptual
+- **출처 신뢰도:** B
+- **신뢰 점수:** 0.90
+- **중복 검사 결과:** 신규 생성 (New discovery)
+
+## 🔗 관련 문서 링크 (Related document links)
+
+### 상위/유사 개념
+- [[외재적 인지 부하 (Extraneous Cognitive Load)]] — DDD의 코드 레벨 오용이 초래하는 불필요하고 파괴적인 인지적 부담의 형태
+- [[팀 토폴로지 (Team Topologies)]] — DDD로 인해 파편화되는 멘탈 모델의 한계를 극복하고, 조직의 인지 부하를 일관성 있게 분산하는 대안적 조직 설계 프레임워크
+
+### 심층 후속 질문 (Deeper Research Questions)
+- 비즈니스 로직을 구현할 때 DDD의 패턴(리포지토리, 애그리거트 등)을 배제하고 인지 부하를 낮게 유지하면서도 복잡성을 관리할 수 있는 구체적인 아키텍처 대안은 무엇인가?
+- 이벤트 스토밍과 유비쿼터스 언어를 '문제 영역'의 논의에만 국한시키고, 이를 '솔루션 공간'의 구조에 반영하지 않도록 경계를 설정하는 실무 가이드라인은 무엇인가?
+- 팀 토폴로지가 DDD와 비교하여 개발자들에게 더 직관적이고 통일된 멘탈 모델을 형성할 수 있는 심리적, 구조적 이유는 무엇인가?
+
+### 실무 적용 맥락 (Practical Application Contexts)
+- **Implementation:** 코드를 구현할 때 DDD에서 파생된 특정 디렉토리/클래스 구조를 강요하기보다, 개발자들이 별도의 학습 없이도 즉각적으로 이해할 수 있는 지루하고 단순한 아키텍처를 선택하여 인지 부하를 줄임.
+- **System Design:** 소프트웨어 설계 초기 단계에서 도메인 전문가와의 의사소통 및 요구사항 명확화를 위한 도구(이벤트 스토밍)로만 DDD를 활용.
+- **Operation / Maintenance:** 코드베이스를 검토할 때, 주니어 개발자나 신규 입사자가 현재의 아키텍처(DDD 등)를 이해하기 위해 과도한 멘탈 모델 구축(인지 부하)을 겪고 있는지 페어 프로그래밍 등을 통해 측정하고 리팩토링 여부를 판단.
+- **Learning Path:** 소프트웨어 아키텍처를 학습할 때 방법론 자체에 매몰되지 않고, 그것이 '인지 부하'에 미치는 영향을 최우선적으로 평가하는 시각 배양.
+
+### 인접 주변 주제 (Adjacent Topics)
+- [[마이크로서비스 아키텍처 (Microservices Architecture)]] — 도메인 경계를 나누는 또 다른 해결 방법이자 과도한 분리로 인해 인지 부하를 폭증시킬 수 있는 아키텍처 패턴.
+- [[유비쿼터스 언어 (Ubiquitous Language)]] — DDD의 핵심 요소로, 다양한 이해관계자 간의 인지적 간극과 의사소통 비용을 줄여주는 수단.
+
+## 🔗 지식 그래프 (Knowledge Graph)
+- **상위/루트:** [[풀이 과정이 담긴 워크드 예제 (worked examples)]]
+- **관련 개념:** [[인지 부하 이론 (Cognitive Load Theory)]], [[외재적 인지 부하 (Extraneous Cognitive Load)]]
+- **참조 맥락:** 과도한 아키텍처 방법론(DDD 등) 도입이 오히려 코드 파악을 어렵게 만들고, 이는 워크드 예제가 해결하고자 하는 '초심자의 외재적 인지 부하 폭증 현상'과 본질적으로 동일한 문제를 소프트웨어 엔지니어링 생태계에 유발함을 이해할 때 참조.
+
+## 📚 출처 (Sources)
+- [S1] 인지 부하가 중요합니다 ("Cognitive load is what matters" 원문) - velog
+
+## 📝 변경 이력 (Change history)
+- 2026-07-11: Initial draft generated via Datacollector_MAC P-Reinforce engine.
+```