TIL - DDD 첫 설계 (10.28)

📚 오늘 공부한 내용

DDD(Domain-Driven Design)를 활용한 항공권 예약 시스템 설계

오늘은 팀원들과 함께 항공권 예약 사이트를 DDD 방식으로 설계하는 작업을 시작했다. 처음 접하는 개념들이 많아 혼란스러웠지만, 그만큼 배울 점도 많았던 하루였다.

유비쿼터스 언어(Ubiquitous Language) 정립

프로젝트 초기 단계에서 가장 먼저 마주한 과제는 용어 통일이었다. 승객 예약 번호를 'PNR'로 할지 'ReservationNumber'로 할지를 두고 팀 내에서 의견이 갈렸다.

이 과정에서 중요한 질문이 나왔다: "유비쿼터스 언어는 일반인도 이해할 수 있는 용어여야 할까, 아니면 기획자와 개발자가 이해하는 도메인 전문 용어여야 할까?"

결국 PNR로 통일하기로 했지만, 이 논의 자체가 의미 있었다. 우선은 결론은 이렇지만 내일 튜터님과 Q&A 시간을 가지며 수정할 계획이 있다.

Context Map 작성의 어려움

Context Map을 그리는 과정에서 여러 혼란스러운 지점들을 마주했다.

1. Customer/Supplier 관계의 남발

아직 DDD에 익숙하지 않다 보니, 대부분의 컨텍스트 관계를 Customer/Supplier로 정의하게 되었다. 각 컨텍스트 간의 관계를 명확히 이해하지 못한 채 "상류-하류" 관계만으로 단순화시킨 것 같아 아쉬움이 남는다.

2. 컨텍스트 경계 설정의 모호함

컨텍스트를 어떤 기준으로 나눠야 할까? 트랜잭션 경계로 나눠야 할지, Entity 단위로 나눠야 할지 명확한 기준을 잡지 못했다. 이 부분은 더 깊이 있는 학습이 필요해 보인다.

중간부터는 개인적으로 뭔가 제자리를 빙빙 돌았던거 같다.

3. 컨텍스트 간 데이터 참조 문제

팀원 중 한 명이 제기한 이슈가 인상적이었다. User 컨텍스트와 Payment 컨텍스트가 별도로 존재할 때, 단순히 마일리지를 조회하기 위해 userId를 계속 들고 다니는 게 맞는 설계일까?

이 질문은 컨텍스트 간의 결합도와 응집도, 그리고 필요한 정보를 어떻게 전달할지에 대한 근본적인 고민을 담고 있었다.

이 부분 또한 내일 튜터님과 Q&A를 통해 해결할 예정이다.

4. Partnership 관계의 모호함

나는 특히 Partnership이라는 양방향 관계에 대한 정확한 정의를 이해하지 못했다. 컨텍스트 간 양방향 관계가 모두 Partnership인지, 아니면 양방향이면서도 상하 관계(Upstream/Downstream)가 존재할 수 있는지 헷갈렸다.

 

아래는 1차 ContextMap 설계물이다.

🎯 앞으로의 과제

• Context Map의 각 관계 패턴(Partnership, Customer/Supplier, Conformist 등)에 대한 명확한 이해 필요
• 컨텍스트 경계를 나누는 실질적인 기준 학습 (비즈니스 능력 단위? 트랜잭션 단위?)
• 컨텍스트 간 데이터 공유와 참조 방식에 대한 Best Practice 탐구
• 실제 항공권 예약 도메인에 대한 더 깊은 이해

🤔 느낀 점

오늘은 답을 찾기보다 좋은 질문들을 발견한 날이었다. DDD는 정답이 명확하지 않고, 팀과 도메인의 맥락에 따라 달라지는 것 같다. 그래서 더 어렵지만, 동시에 더 흥미로운 것 같다. 혼란스럽지만 이 혼란 속에서 점점 성장하고 있다는 느낌이 든다.

내일은 오늘의 질문들에 대한 답을 찾기 위해 DDD 관련 자료를 더 찾아보고, 팀원들과 함께 다시 논의해봐야겠다.

오늘도 나는 어제의 나보다 성장했다.