Brain핵심 인사이트 (3줄 요약)
- 본질: DDD(Domain Driven Design)는 소프트웨어의 복잡성을 해결하기 위해 기술적인 구현보다 비즈니스 도메인(업무 지식) 자체의 논리에 집중하여 설계하는 방법론이다.
- 가치: 개발자와 업무 전문가가 동일한 언어(Ubiquitous Language)를 사용해 소통 오해를 없애고, 복잡한 시스템을 명확한 경계(Bounded Context)로 나누어 유지보수성을 극대화한다.
- 판단 포인트: MSA 구축 시 "서비스 경계를 어디로 나눌 것인가?"라는 질문에 대해 비즈니스 맥락을 기준으로 가장 명확한 답을 제시해주는 도구다.
Ⅰ. 개요 및 필요성
많은 IT 프로젝트가 실패하는 이유는 개발자가 비즈니스를 잘못 이해하거나, 코드가 너무 복잡해져서 나중에 고칠 수 없게 되기 때문이다. 에릭 에반스가 제안한 DDD는 "프로그램은 비즈니스를 그대로 투영해야 한다"고 말한다. 특히 MSA로 전환할 때 무작정 기능별로 쪼개면 데이터가 꼬이게 된다. DDD는 업무의 '문맥(Context)'을 기준으로 경계를 나누고, 그 안에서만 의미가 통하는 언어를 정의하여 거대한 스파게티 시스템을 질서 정연한 작은 방들로 분리한다.
📢 섹션 요약 비유: DDD는 '전문 분야별 사전 만들기'다. '주문'이라는 단어가 마케팅팀(이벤트 응모)과 배송팀(배송지 정보)에서 다른 의미로 쓰일 때, 이를 섞지 않고 각자의 문맥(Context)에 맞게 따로 정의하는 것이다.
Ⅱ. 아키텍처 및 핵심 원리
1. 전략적 설계 (Strategic Design) - 큰 그림 그리기
- 보편적 언어 (Ubiquitous Language): 개발자, 기획자, 전문가가 모두 공통으로 사용하는 용어집. 코드 내 변수명도 이 언어를 따른다.
- 바운디드 컨텍스트 (Bounded Context): 모델이 적용되는 명확한 경계. 이 경계가 곧 마이크로서비스의 단위가 된다.
- 컨텍스트 맵 (Context Map): 여러 컨텍스트 간의 관계(누가 데이터를 주는지, 누가 받는지)를 도식화한 지도.
2. 전술적 설계 (Tactical Design) - 상세 구현
- 애그리게이트 (Aggregate): 데이터 변경의 단위가 되는 연관 객체들의 묶음. (예: 주문-주문항목)
- 엔티티 (Entity): 식별자(ID)를 가진 객체. (예: 회원)
- 값 객체 (Value Object): 속성만으로 정의되는 불변 객체. (예: 주소, 금액)
- 리포지토리 (Repository): 애그리게이트를 저장하고 불러오는 인터페이스.
📢 섹션 요약 비유: 애그리게이트는 '하나의 세트 상품'이다. 햄버거 세트에서 감자튀김만 따로 바꾸면 안 되듯이, 연관된 정보를 한꺼번에 관리하여 데이터 깨짐을 막는다.
Ⅲ. 비교 및 연결
데이터 중심 설계 vs 도메인 중심 설계 (DDD)
| 비교 항목 | 데이터 중심 설계 (전통적 ERD 방식) | 도메인 주도 설계 (DDD) |
|---|---|---|
| 설계의 시작 | DB 테이블 스키마, 관계도(ERD) | 비즈니스 행위와 업무 전문가의 언어 |
| 모델의 성격 | 상태(Data) 중심 | 행위(Behavior) 중심 |
| 변화 대응력 | 테이블 수정 시 앱 전체 영향 (경직됨) | 경계 내 모델만 수정하면 됨 (유연함) |
| 적합한 시스템 | 단순 CRUD 위주 시스템 | 복잡한 비즈니스 로직을 가진 MSA |
📢 섹션 요약 비유: 데이터 중심 설계는 건물을 지을 때 벽돌(DB)부터 일단 쌓는 것이고, DDD는 건물의 용도(도메인)와 사람들의 동선(비즈니스 흐름)부터 철저히 계획하는 방식이다.
Ⅳ. 실무 적용 및 기술사 판단
기술사 핵심 포인트:
- 이벤트 스토밍 (Event Storming): 포스트잇을 활용해 비즈니스 이벤트를 나열하며 바운디드 컨텍스트를 찾아내는 워크숍 기법을 반드시 언급해야 한다.
- 애그리게이트 루트 (Aggregate Root): 외부에서 애그리게이트 내부 객체에 직접 접근하지 못하게 막고, 루트를 통해서만 소통하여 데이터 정합성을 지키는 원칙이 핵심이다.
- MSA와의 조화: DDD로 나눈 바운디드 컨텍스트는 서비스 간의 결합도를 낮추고 독립적인 배포를 가능케 하는 MSA의 이론적 토대다.
📢 섹션 요약 비유: DDD는 '비즈니스 언어로 코딩하기'다. 코드를 읽는 것만으로도 실제 업무가 어떻게 돌아가는지 이해할 수 있게 만드는 것이 궁극적 목표다.
Ⅴ. 기대효과 및 결론
DDD는 단순히 기술적인 패턴이 아니라, 비즈니스와 IT의 간극을 좁히는 소통의 철학이다. 기술의 유행은 변해도 비즈니스의 본질은 쉽게 변하지 않는다. 그 본질을 코드에 녹여냄으로써 소프트웨어의 생명력을 연장하고 복잡성을 통제할 수 있다. 기술사 시험에서는 전략적 설계와 전술적 설계의 조화, 그리고 보편적 언어를 통한 소통의 가치를 강조하는 것이 중요하다.
📢 섹션 요약 비유: DDD는 IT 세상의 '통번역 시스템'이다. 비즈니스 사람과 개발자가 서로 다른 언어를 써서 싸우지 않고 하나의 목표로 나아가게 도와준다.
📌 관련 개념 맵
| 개념 | 연관 키워드 | 관계 |
|---|---|---|
| Ubiquitous Language | 공통 언어, 용어 사전 | 소통의 벽을 허무는 DDD의 기초 |
| Bounded Context | 서비스 경계, MSA 단위 | 모델의 의미가 유효한 영역 설정 |
| Aggregate | 트랜잭션 단위, 루트 | 데이터 정합성을 지키는 최소한의 묶음 |
| 이벤트 스토밍 | 포스트잇, 비즈니스 흐름 | 도메인 경계를 찾아내는 설계 워크숍 |
👶 어린이를 위한 3줄 비유 설명
- 어려운 컴퓨터 용어 대신, 우리가 실제 생활에서 쓰는 말로 프로그램을 만드는 약속이에요.
- 복잡한 업무를 작은 팀별로 나누어서, 서로 방해하지 않고 자기 일만 잘하게 구역을 나눠요.
- 마치 사전처럼 단어의 뜻을 명확히 정해서 누구나 똑같이 이해할 수 있게 만들어요.