2.2 KiB
2.2 KiB
id, category, confidence_score, tags, last_reinforced
| id | category | confidence_score | tags | last_reinforced | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| P-REINFORCE-AUTO-DDDE-001 | 10_Wiki/💡 Topics/AI | 0.96 |
|
2026-04-20 |
Domain-Driven-Design
📌 한 줄 통찰 (The Karpathy Summary)
"비즈니스의 언어로 코딩하기: 소프트웨어의 복잡성을 해결하기 위해, 기술적 구현보다 비즈니스 도메인(업무 지식)을 핵심으로 두고 전문가와 개발자가 똑같은 단어(Ubiquitous Language)를 쓰며 함께 설계하는 철학."
📖 구조화된 지식 (Synthesized Content)
도메인 주도 설계(DDD, Domain-Driven-Design)는 복잡한 소프트웨어 프로젝트를 성공적으로 이끌기 위한 아키텍처적 접근 방식입니다.
- 핵심 개념:
- Ubiquitous Language: 기획자, 개발자, 마케터 모두가 사용하는 공용어. 코드 내 클래스명에도 그대로 반영.
- Bounded Context: 동일한 용어라도 맥락에 따라 의미가 달라질 수 있는 경계를 설정 (예: '상품'이 주문 팀과 물류 팀에서 갖는 다른 의미).
- Aggregate: 데이터 변경의 단위로 묶여있는 객체들의 덩어리.
- 왜 중요한가?:
- 기술적 탁상공론에 빠지지 않고 실제 비즈니스 가치를 가장 정확하게 구현하며, 거대 시스템을 책임 소재가 명확한 단위로 쪼갤 수 있음.
⚠️ 모순 및 업데이트 (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.