32 lines
2.2 KiB
Markdown
32 lines
2.2 KiB
Markdown
---
|
|
id: P-REINFORCE-AUTO-DDDE-001
|
|
category: "[[10_Wiki/💡 Topics/AI]]"
|
|
confidence_score: 0.96
|
|
tags: [auto-reinforced, domain-driven-design, ddd, software-architecture, ubiquituous-language, clean-architecture]
|
|
last_reinforced: 2026-04-20
|
|
---
|
|
|
|
# [[Domain-Driven-Design]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> "비즈니스의 언어로 코딩하기: 소프트웨어의 복잡성을 해결하기 위해, 기술적 구현보다 비즈니스 도메인(업무 지식)을 핵심으로 두고 전문가와 개발자가 똑같은 단어(Ubiquitous Language)를 쓰며 함께 설계하는 철학."
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
도메인 주도 설계(DDD, Domain-Driven-Design)는 복잡한 소프트웨어 프로젝트를 성공적으로 이끌기 위한 아키텍처적 접근 방식입니다.
|
|
|
|
1. **핵심 개념**:
|
|
* **Ubiquitous Language**: 기획자, 개발자, 마케터 모두가 사용하는 공용어. 코드 내 클래스명에도 그대로 반영.
|
|
* **Bounded Context**: 동일한 용어라도 맥락에 따라 의미가 달라질 수 있는 경계를 설정 (예: '상품'이 주문 팀과 물류 팀에서 갖는 다른 의미).
|
|
* **Aggregate**: 데이터 변경의 단위로 묶여있는 객체들의 덩어리.
|
|
2. **왜 중요한가?**:
|
|
* 기술적 탁상공론에 빠지지 않고 실제 비즈니스 가치를 가장 정확하게 구현하며, 거대 시스템을 책임 소재가 명확한 단위로 쪼갤 수 있음.
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌**: 과거에는 DB 테이블(데이터 중심)을 먼저 설계하는 정책이었으나, DDD 정책은 업무 프로세스(도메인 로직 중심)를 먼저 설계하는 정책으로 패러다임을 혁신함(RL Update).
|
|
- **정책 변화(RL Update)**: 마이크로서비스(MSA) 정책을 수립할 때 '어디서 서비스를 쪼갤 것인가'의 기준 정책으로 Bounded Context가 사용되며 분산 시스템 설계의 근간 정책이 됨.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- [[Clean-Architecture-TypeScript]], [[Distributed-Systems]], [[Scalability]], [[Technical-Architecture]], [[Strategic-Planning]]
|
|
- **Modern Tech/Tools**: Event Storming, NestJS/Spring Boot context design.
|
|
---
|