Files
2nd/10_Wiki/Topics/AI/Domain-Driven-Design (DDD).md
T

1.9 KiB

id, category, confidence_score, tags, last_reinforced
id category confidence_score tags last_reinforced
P-REINFORCE-AI-DDD 10_Wiki/💡 Topics/AI 0.99
SoftwareEngineering
DDD
Architecture
DomainDrivenDesign
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)