💡 핵심 인사이트
도메인 주도 설계(DDD, Domain-Driven Design)는 에릭 에반스(Eric Evans)가 창안한 개발 철학으로, 개발자들이 멍청한 DB 테이블 엑셀 뼈대(Data-driven)부터 그리고 코딩을 시작하는 최악의 관행을 버리고, 철저하게 '현실 세계의 비즈니스 지식(Domain)'을 중심에 두고 그 지식과 100% 동일하게 움직이는 살아 숨 쉬는 객체지향 코드를 짜는 웅대한 설계 기법입니다.

Ⅰ. 기존 데이터 주도(DB 중심) 설계의 한계

과거의 낡은 개발 방식은 쇼핑몰을 만들 때 무조건 ERD(데이터베이스 표)부터 그렸습니다.

• [사용자] - [주문] - [상품] 네모난 박스를 긋고 외래 키(FK)를 꽂습니다.
• 그리고 개발자는 오직 이 DB에 값을 넣고 빼는(CRUD) 멍청한 코드만 짰습니다.
• 결과: "VIP 회원이 10만 원 넘게 사면 쿠폰을 준다"는 비즈니스 핵심 로직(지식)은 갈 곳을 잃고 엉뚱한 화면 코드(Controller)나 DB 저장소(SQL 쿼리)에 스파게티처럼 섞여 들어가 시스템이 부패해 버립니다.

Ⅱ. DDD의 핵심 사상 (도메인과 보편적 언어)

DDD는 DB를 나중에 생각하고, 가장 중요한 **'비즈니스 도메인(현업 지식)'**부터 코드로 녹여내자고 주장합니다.

1. 유비쿼터스 언어 (Ubiquitous Language / 보편적 언어)

• "개발자, 기획자, 영업팀이 제발 하나의 똑같은 단어를 쓰자!"
• 현업에서 "결제를 취소하면 환불 대기 상태가 된다"라고 말한다면, 개발자도 데이터베이스의 status=3이라고 암호문을 쓰지 말고, 자바 소스 코드 안에 public void cancelPayment(), state = REFUND_PENDING이라고 토씨 하나 안 틀리고 똑같이 코드로 타이핑해야 합니다. 소스 코드 자체가 비즈니스 산문이 되게 만드는 것입니다.

2. 도메인 모델 (Domain Model) 중심

• 모든 비즈니스 로직(VIP 쿠폰 발행 등)은 DB나 UI가 아니라 오직 '도메인 계층(순수한 객체)' 안에서만 처리되도록 격리시킵니다. 나중에 오라클 DB를 MySQL로 바꿔도 도메인 코드는 단 한 줄도 타격받지 않는 완벽한 독립성을 갖춥니다.

Ⅲ. 바운디드 컨텍스트 (Bounded Context)와 MSA

DDD가 수십 년이 지난 지금 '마이크로서비스 아키텍처(MSA)' 시대에 다시 전성기를 맞은 이유입니다.

거대한 쿠팡 같은 시스템에서 **'상품'**이라는 단어는 부서마다 뜻이 다릅니다.

• 주문팀: 상품 = 썸네일 이미지, 가격, 옵션 사이즈 (보여주는 것).
• 배송팀: 상품 = 가로 세로 부피, 박스 무게, 파손 위험도 (박스에 넣는 것).

이 두 개를 억지로 하나의 뚱뚱한 [상품] DB 테이블로 묶으려니 매번 부서끼리 멱살을 잡았습니다. DDD의 바운디드 컨텍스트 전략: "억지로 합치지 마! 주문 컨텍스트(경계) 안에서의 상품 클래스와, 배송 컨텍스트(경계) 안에서의 상품 클래스를 아예 물리적으로 두 개로 찢어서 따로 만들어!" 이 도메인 경계를 찢어버리는 행위가 바로 거대한 시스템을 여러 개의 쪼개진 컨테이너(서버)로 나누는 **MSA(마이크로서비스)**의 가장 완벽한 쪼개기 기준(식칼)이 되었습니다.

📢 섹션 요약 비유: 전통적 개발이 뼈대(DB)부터 만들고 살(기능)을 억지로 이어 붙이는 **'좀비(프랑켄슈타인) 조립'**이라면, DDD는 사람의 성격과 사고방식(도메인 지식, 비즈니스 룰)을 완벽하게 이해하고 뇌(도메인 모델)에 주입한 뒤, 그 성격에 맞게 뼈와 살이 자연스럽게 자라나게 하는 **'인공 생명체 창조'**입니다. 뇌(도메인)만 튼튼하면 나중에 입는 옷(웹이든 모바일 앱이든)은 언제든 갈아입을 수 있습니다.