30 lines
1.9 KiB
Markdown
30 lines
1.9 KiB
Markdown
---
|
|
id: P-REINFORCE-AI-DDD
|
|
category: "[[10_Wiki/💡 Topics/AI]]"
|
|
confidence_score: 0.99
|
|
tags: [SoftwareEngineering, DDD, Architecture, DomainDrivenDesign]
|
|
last_reinforced: 2026-04-20
|
|
---
|
|
|
|
# [[Domain-Driven-Design (DDD)]] (도메인 주도 설계)
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> "기술의 언어가 아닌, 비즈니스의 언어로 코드를 짜는 철학." 복잡한 소프트웨어를 해결하기 위해 도메인(비즈니스 핵심 영역)을 모델링의 중심에 두고, 개발자와 전문가가 동일한 언어(Ubiquitous Language)를 공유하며 설계를 이어나가는 방식이다.
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
- **Ubiquitous Language (보편적 언어)**: 기획자, 디자이너, 개발자가 '결제'를 각자 다르게 이해하지 않도록 코드와 문서에서 동일한 용어를 사용함.
|
|
- **Strategic Design**:
|
|
- **Bounded Context**: 거대한 도메인을 논리적 경계로 쪼개어 모델 간의 간섭을 최소화함.
|
|
- **Context Map**: 여러 컨텍스트 간의 관계를 도식화함.
|
|
- **Tactical Design**:
|
|
- **Entity vs Value Object**: 식별자가 중요한가(사용자 ID), 속성값이 중요한가(주소, 금액).
|
|
- **Aggregate**: 데이터 변경의 단위가 되는 객체 묶음.
|
|
- **Repository**: 데이터 저장소에 대한 추상화 계층.
|
|
|
|
## ⚠️ 모순 및 업데이트 (RL Update)
|
|
- DDD를 모든 곳에 적용하려다 보면 'Over-engineering'에 빠지기 쉽다. 단순한 CRUD 앱에 DDD를 도입하는 것은 시간 낭비일 수 있다. 최근에는 MSA(마이크로서비스 아키텍처)의 경계를 나누는 기초 도구로 DDD가 필수적으로 쓰이지만, 구현의 복잡성을 줄이기 위해 핵심 도메인이 아닌 곳은 가볍게 짜는 실용적인 접근(Clean DDD)이 선호된다.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- Related: [[Bounded-Contexts]] , [[Ubiquitous-Language-Encoding]]
|
|
- Pattern: [[Value-Object-Pattern]]
|