💡 MSA와 DDD 시리즈에서는 다음과 같은 순으로 포스팅이 진행됩니다.
(1) 왜 내가 MSA와 DDD 에 관심을 갖게 되었을까?
(2) DDD를 활용한 MSA
(3) DDD엔 어떤 문제가? feat. CQRS
(4) 모놀리식와 MSA의 조합

글에 들어가기 앞서

---

MSA와 DDD 에 대해 학습하고 포스팅하기 전, 프로젝트 경험을 하면서 느낀바를 정리하는 비중이 큰 프롤로그와 같은 글이다. MSA와 DDD에 대해서 읽고 싶다면, 바로 다음 포스팅을 참고하길 바란다.

😤 왜 내가 MSA와 DDD 에 관심을 갖게 되었을까?

---

프로그래머스 백엔드 데브코스 1기 교육과정을 진행하면서 ‘Sky Scanner’의 API 서버를 클론코딩하는 CarrierRoute 프로젝트와 동네 이벤트 관리 서비스인 Everevent 프로젝트를 경험하였다.

두 프로젝트를 진행하면서 MSA와 DDD에 내가 관심을 갖게된 문제들을 맞닥뜨렸는데 MSA와 DDD에 대한 공부를 하기 전에 그 계기에 대해서 먼저 정리해보면 좋을 것 같아 이번 포스팅을 준비하게 되었다.

1. CarrierRoute 프로젝트

---

CarrierRoute 프로젝트 링크

CarrierRoute 프로젝트에서 3명의 팀원이 3가지 도메인을 각자 분담하여 개발하였다.

• 항공편
• 호텔
• 렌트카

나는 여기서 항공편 도메인을 맡아 다음과 같은 API 구현을 맡았다.

API	Http Method	URI
항공권 전체 조회	GET	/api/v1/flights/
항공편 전체 조회	GET	/api/v1/flights/
항공편 단일 조회	GET	/api/v1/flights/{flightId}
항공편 예약	POST	/api/v1/bookings/flights
항공편 예약 조회	GET	/api/v1/bookings/flights
항공편 예약 상세조회	GET	/api/v1/bookings/flights/{bookingId}
항공편 예약 취소	DELETE	/api/v1/bookings/flights/{bookingId}

What is problem?

---

해당 프로젝트는 애자일 프로세스 중 하나인 스크럼 방식으로 개발이 진행됐다.

우리팀은 2주 프로젝트를 3번의 스프린트로 나누어 일정을 계획하였고, 짧은 일정이지만 반복적인 주기를 갖으며 지속적인 개선이 가능한 애자일 프로세스에 기대를 갖고 프로젝트에 임했다.

첫 번째 스프린트 때,

• 요구사항 분석
• 유즈케이스 작성
• API 설계

를 하고 두 번째 스프린트 땐, ERD 설계를 진행하고 바로 코드 개발에 들어갔다.

하지만 각자 분담한 코드개발에 들어갔을 때, 나는 요구사항과 API에 맞게 ERD가 잘 분리되어 있지 않는 문제점들을 발견하였다.

결국 다른 팀원들이 코드 개발을 지속적으로 이루어나갈 때, 나는 ERD 재수정 작업을 하며, 어려운 부분이 있을 땐 게더타운에 접속하여 팀원과 멘토님께 질문을 던지며 ERD를 재설계하였다.

ERD를 재설계하면서 깨달은 점 은 다음과 같았다.

• 도메인이 기능에 맞게 제대로 분리 되어지지 않았다.
  • 짧은 프로젝트 기간으로 인해 단순히 항공편, 호텔, 렌트카 3가지 도메인으로 3명이서 역할을 나눠 서로 개발에 대한 간섭을 최소화하려고 했었다.
  • 하지만 그 내부에는 예약하는 도메인, 결제하는 도메인 등 분리해야 할 도메인들이 많이 존재했다.
  • 또한 진정한 애자일 프로세스를 지향하려면 서로에 대한 도메인을 이해를 바탕으로 개발이 이루어져야 페어 프로그래밍등이 수월하다.
• 애자일 프로세스가 스프린트라는 주기를 갖으며 지속적인 개선을 하는 프로세스이지만 뼈대를 잡는 ERD 설계는 깊게 고민하여 완성 해야한다.
  • 그렇지 않으면 개발 도중에 ERD 설계의 허점을 발견 시, 수정 시간이 늘어난다.

CarrierRoute 프로젝트 기간 땐, 멘토님과 ‘도메인을 잘 분리하고 설계하는 방법'에 대해서 이야기를 많이 나눴다. 멘토님은 자신의 회사에서 적용 중인 DDD와 이벤트 스토밍 방식에 대해서 이야기해주셨는데, 도메인을 제대로 분리하지 못한 채 개발을 하던터라 더욱 내용이 와닿았었다.

2. Everevent 프로젝트

---

Everevent 프로젝트 링크

Everevent 프로젝트에서도 CarrierRoute 프로젝트와 마찬가지로 3명의 팀원이서 진행하였다.

학창시절 부터 프로젝트들을 해오면서 느껴왔던건데 매번 프로젝트를 진행하면 다음 프로젝트 때 ‘조금의 성장’을 몸소 체감한다는 것이다. (🤭)

CarrierRoute 프로젝트를 마치고 바로 한달 뒤, Everevent 프로젝트를 하면서 느꼈던 ‘조금의 성장’을 미리 말하자면 다음과 같다. (도메인 분리 및 설계 관점에서만)

1. 도메인을 API를 설계와 함께, 자원 관점에서 더욱 세부적으로 분리하였다.
   1. 멤버, 이벤트, 가게, 리뷰, 즐겨찾기, 좋아요 로 분리하였으며 데이터가 저장되고 조회되는 것을 고려하여 ERD와 함께 API를 설계하니, Restful API 설계 뿐만 아니라, 개발 또한 쉽게 할 수 있었다.
2. ‘특정 도메인 - 개인’ 식으로 역할을 나누지 않았다.
   1. 이전 프로젝트에서 잘못했던 점, 덕분에 각자 모든 도메인을 이해하고 있어 페어 프로그래밍이 수월해졌다.

1. 도메인을 API를 설계와 함께 ‘자원 관점’에서 더욱 세부적으로 분리하였다.

---

이전 프로젝트에 비해 상대적으로 요구사항이 간단해서 분리하기 쉬웠을 수 있지만, 가시적으로 ‘세분화된 도메인’을 볼 수 있어서 만족스러웠다.

Everevent Project ERD

---

2. ‘특정 도메인 - 개인’ 식으로 역할을 나누지 않았다.

---

이전 프로젝트에서 잘못했던 점을 고치기 위해서 어떻게 해야할지 고민이 많았다. 운이 좋게도(?!) 이전 방식의 틀에서 벗어나지 못한 방법으로 역할을 나누려다가 이걸 게더타운에서 지켜본 멘토님의 피드백에 정신이 번쩍했던 기억이 있다.

“최대한 작은 단위로 이슈를 파고 우선순위 별로 정렬한 뒤, 다 끝낸 사람이 다음 이슈를 해결하는 방식으로 해보세요!” - 멘토님 Says

---

그래서 다음과 같은 규칙을 통해 역할을 분담하였고 이전에 느끼지 못했던 여러 장점들을 발견할 수 있었다.

• 각자 능동적으로 자신의 이슈를 찾아 해결할 수 있다.
• 모두가 도메인을 이해하고 있어 페어 프로그래밍 시, 효율적이다.
• 역할은 API 별로 나눴지만, 이슈를 잘개 쪼개니 병목현상이 줄어들었다.

3. 글을 마치며

---

내 생각이 “서버? 개발만 잘하면 되지” 에서 “개발 잘하려면 도메인 설계에 대한 깊이가 필요하다.” 더 나아가, 기능별 서비스를 독립적인 모듈로 애플리케이션을 관리하는 “MSA 공부해보자!” 로 바뀌게 된 소중한 경험인 두 프로젝트였다.

각 부분 부분 마다 느낀점을 즉흥적으로 적느라 장황했지만,

두 프로젝트를 통해

• 도메인 설계의 중요성
• 서비스 아키텍처의 중요성

을 알게 됐던 것 같다.

그래서 다음 포스팅 부터는 DDD(도메인 주도 개발)과 MSA(마이크로 서비스 아키텍처)에 대해서 공부하고자 한다.
화이팅! 🤛🏻