Initial Commit: Reinforced Knowledge Wiki v1.0 - Pure Origin

2026-04-20 14:26:57 +09:00
commit f4e731b115
2141 changed files with 63988 additions and 0 deletions
@@ -0,0 +1,33 @@
+---
+id: P-REINFORCE-AUTO-F2DA4C
+category: "[[10_Wiki/💡 Topics/Programming & Language]]"
+confidence_score: 0.90
+tags: [auto-reinforced]
+last_reinforced: 2026-04-20
+github_commit: "[P-Reinforce] Continuous Worker - 도메인 기반 설계 (DDD)"
+---
+
+# [[도메인 기반 설계 (DDD)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 도메인 기반 설계(DDD)는 비즈니스 도메인에 맞춰 소프트웨어를 모델링하는 설계 접근법으로, TypeScript의 타입 시스템에서는 의미적으로 다른 데이터를 엄격하게 분리하여 시스템의 무결성을 보호하는 데 활용됩니다 [1]. 특히 브랜디드 타입(Branded Types)과 불변성(Immutability)을 통해 도메인 모델 내에서 데이터가 무분별하게 섞이거나 오염되는 것을 방지하여 예측 가능성을 극대화합니다 [1-3].
+
+## 📖 구조화된 지식 (Synthesized Content)
+* **브랜디드 타입(Branded Types)의 활용:** 도메인 기반 설계에서는 기본 타입(Primitive Type)에만 의존하는 문제를 해결하기 위해 브랜디드 타입을 적극 활용합니다. 예를 들어, 구조적으로 동일한 `string` 타입이더라도 `UserId`와 `OrderId`를 엄격히 분리함으로써 도메인 데이터가 서로 섞이는 것을 방지할 수 있습니다 [1, 2, 4, 5].
+* **데이터 오염 방지와 신분증 시스템:** DDD 구조에서 타입 시스템은 외부의 불안정한 데이터로부터 내부 로직을 보호하는 역할을 합니다. 검증된 데이터(예: `SanitizedString`)만이 시스템의 내부 로직으로 진입하도록 강제할 수 있으며, 이는 마치 외부 침입으로부터 성채를 보호하는 "신분증 시스템"과 같이 작동합니다 [1, 2].
+* **도메인 모델의 불변성(Immutability) 확립:** 도메인 모델이나 엔티티 클래스를 구현할 때 데이터의 무결성을 유지하는 것은 매우 중요합니다. `readonly` 수식어를 사용하여 불변적인 식별자 속성(Identity properties)과 변경 가능한 상태(Mutable state)를 명확하게 구분함으로써 데이터의 신뢰성을 보장할 수 있습니다 [3].
+* **도메인 에러(Domain Error) 처리:** 도메인 로직 내에서 예기치 않은 상태나 유효하지 않은 데이터가 발생할 경우, 도메인 예외(DomainException)를 던지고 미들웨어가 이를 전역적으로 처리하게 함으로써 비즈니스 흐름을 제어하는 복잡한 에러 체크 로직을 줄일 수 있습니다 [6, 7]. 다만, 도메인의 관심사 분리(Separation of Concerns)를 지키지 않은 섣부른 추상화는 시스템 코드를 비대하게 만들고 관리를 어렵게 할 수 있으므로 주의해야 합니다 [8].
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
+- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
+
+## 🔗 지식 연결 (Graph)
+- **Related Topics:** [[브랜디드 타입 (Branded Types)]], [[불변성 (Immutability)]], [[구조적 타이핑 (Structural Typing)]]
+- **Projects/Contexts:** [[TypeScript 타입 시스템을 활용한 내부 로직 보호 및 데이터 검증]]
+- **Contradictions/Notes:** 예외(Exception) 처리에 대해, 도메인 비즈니스 흐름을 단순히 제어할 목적(if-else를 대체하는 용도)으로 예외를 남용하는 것은 지양해야 하지만, 예기치 않은 상황이나 검증 실패 시 도메인 에러를 발생시키고 이를 전역 미들웨어에서 처리하도록 위임하는 방어적 프로그래밍 패턴은 적절한 수비 전략으로 권장됩니다 [6, 7].
+
+---
+*Last updated: 2026-04-18*
+- Raw Source: [[00_Raw/2026-04-20/도메인 기반 설계 (DDD).md]]
+---