219. 도메인 주도 설계 (DDD, Domain-Driven Design) - 에릭 에반스 복잡성 비즈니스 도메인 유비쿼터스 언어 바운디드 컨텍스트 MSA

핵심 인사이트: (마이크로서비스 MSA의 영혼) 은행 앱을 만들 때 개발자들은 맨날 "DB 테이블에 잔고(Int) 칼럼 파고, 회원(Varchar) 칼럼 뚫자!"라며 '엑셀 칸(데이터)'부터 그리기 시작했다. 그러다 보니 정작 은행원(업무 전문가)이 "야, '마이너스 통장 한도 초과 시 이자 계산'은 어떻게 작동하게 했어?" 물어보면 개발자가 못 알아먹고 벙찐다. 에릭 에반스가 분노하며 책을 던졌다. "야! 코딩을 시작할 때 제발 DB 엑셀 칸부터 그리지 마!! 네가 만드는 건 '은행 업무(Domain)' 시스템이야! 개발자 놈들이랑 은행원(전문가)이 한 방에 모여서 며칠 밤을 새우며 '대출', '이자', '상환'이라는 똑같은 단어(유비쿼터스 언어)로 화이트보드에 그림부터 그려!! 코드는 그 화이트보드 그림(도메인)을 100% 똑같이 자바로 베껴 쓰기만 하면 되는 거야!!" 소프트웨어의 중심을 기계(DB)에서 현실 세계의 비즈니스(도메인)로 멱살 잡고 끌고 온 위대한 설계 철학, DDD다.

Ⅰ. 데이터 주도 설계(Data-Driven Design)의 처참한 실패

• 과거엔 시스템을 짤 때 무조건 **"DB 테이블(E-R 다이어그램)을 어떻게 예쁘게 만들까?"**부터 고민했습니다.
• 결과적으로 시스템이 은행의 '진짜 복잡한 이자 계산 규칙(비즈니스 로직)'을 담지 못하고, 그냥 데이터를 넣고 빼는 멍청한 서류철(CRUD 기계)로 전락해 버렸습니다.

Ⅱ. 도메인 주도 설계 (DDD)의 개념 🌟 에릭 에반스 (Eric Evans)

• 도메인 (Domain): 소프트웨어가 해결하고자 하는 현실 세계의 '업무 영역' (예: 쇼핑몰 도메인, 은행 도메인, 물류 도메인).
• 개념: 기술(DB, 프레임워크) 중심의 사고방식을 철저히 배제하고, 해결해야 할 핵심 비즈니스 로직(도메인 모델)을 가장 중심에 두고, 개발자와 도메인 전문가(현업 실무자)가 완벽하게 동일한 언어로 소통하며 시스템의 뼈대를 설계해 나가는 극단적 비즈니스 중심의 소프트웨어 설계 철학입니다.
• 현대 마이크로서비스(213번 MSA) 생태계에서 서비스(캡슐)를 어떻게 쪼갤지 결정하는 절대적인 교과서(가이드라인) 역할을 합니다.

Ⅲ. DDD를 지배하는 2대 핵심 기둥 🌟 핵심 기출 🌟

이 두 개를 모르면 DDD를 논할 수 없습니다. (220, 221번 문서에서 자세히 파고듭니다.)

1. 전략적 설계 (Strategic Design) - "숲을 보며 땅 자르기"

• 전체 시스템이라는 거대한 숲을 봅니다.
• 쇼핑몰이라는 거대한 덩어리를 "야, 이거 통짜로 짜지 말고 [결제], [배송], [회원]이라는 3개의 완벽히 독립된 구역(Bounded Context)으로 쪼개버리자!"라고 거시적인 경계선(MSA의 캡슐 선)을 긋는 작업입니다.
• 핵심 도구: 유비쿼터스 언어(Ubiquitous Language), 바운디드 컨텍스트(Bounded Context).

2. 전술적 설계 (Tactical Design) - "나무를 예쁘게 조각하기"

• 전략적 설계에서 쪼개놓은 작은 방([결제] 방) 안에 들어가서, 실제 자바(Java) 코드를 어떤 패턴으로 예쁘게 짤지 디테일하게 설계하는 현미경 작업입니다.
• 핵심 도구: 엔티티(Entity), 값 객체(Value Object), 애플리케이션 서비스, 222번 애그리게이트(Aggregate), 리포지토리(Repository) 등 객체지향의 끝판왕 패턴들을 사용해 도메인 모델을 깎습니다.

Ⅳ. 왜 지금 DDD가 미친 듯이 핫한가? (MSA와의 찰떡궁합)

• 213번 MSA 챕터에서 1,000만 줄짜리 코드를 100개의 컨테이너로 갈기갈기 찢어야 한다고 했습니다.
• 근데 **"어떤 기준으로 찢어야(경계를 그어야) 완벽하게 독립적인 캡슐이 나오지?"**라는 질문에 수많은 회사가 대답을 못 하고 스파게티로 찢었다가 폭망했습니다.
• 에릭 에반스의 DDD(전략적 설계)가 15년 전에 그 정답을 책에 써놨기 때문입니다. "현실 세계의 비즈니스 업무 경계(Bounded Context)를 기준으로 찢어라!" 이 위대한 진리가 MSA 시대의 복음이 되어 전 세계 개발자를 구원했습니다.

📢 섹션 요약 비유: 기존의 데이터 주도 설계는 병원을 지을 때 건축가(개발자)가 의사(도메인 전문가)의 말은 듣지도 않고 "일단 시멘트로 벽돌(DB 테이블) 1,000개부터 찍어내자!"라며 벽돌부터 예쁘게 쌓아 올린 짓입니다. 다 지어놓고 보니 수술실 문이 좁아서 침대가 못 들어가는 코미디가 발생합니다(비즈니스 붕괴). **도메인 주도 설계(DDD)**는 건축가가 벽돌을 내려놓고, 의사와 함께 도화지 앞에 앉는 것입니다. 의사가 "수술실에서는 환자의 피가 튀니까(비즈니스 요구사항), 동선이 이렇게 되어야 해!"라고 말하면, 건축가와 의사가 **'수술실 동선(유비쿼터스 언어)'**이라는 공통의 단어로 도면(도메인 모델)을 완벽하게 그립니다. 그리고 병원을 '응급실 구역', '외래 진료 구역'(바운디드 컨텍스트)으로 명확히 벽을 쳐서 쪼갭니다(전략적 설계). 도면이 100% 완성된 후에야 비로소 시멘트와 벽돌(DB와 코드)을 가져와 그 도면을 현실에 그대로 복사해서 짓는(전술적 설계), 소프트웨어의 영혼(비즈니스 로직)을 기계(DB)보다 우위에 두는 궁극의 장인 정신입니다.