[도메인 주도 설계 철저 입문] 1. 도메인 주도 설계 읽게 된 이유

www.inhabas.com rest 개편 작업 중,

 

파일 업로드 및 다운로드에 관한 모듈을 따로 생성해야할 필요가 느껴졌다.

 

그러면서 프로젝트 구조에 관한 고민을 하게 됐다. (아래 글 참고)

[Spring boot] 6. 멀티모듈? MSA? 좋은 아키텍쳐? 도대체 뭐야?!

 

기존에는 모노리식으로 작업하고 있었다.

 

물론 최대한 영역을 나누어, 의미상 모듈처럼 분리될 수 있도록 "최대한" 의존성을 나누며 작업하고 있었다.

​

 

 

프로젝트 폴더 구조가 domain / controller / service 이런 식으로 되어 있었는데,

 

점점 기능이 많아지면서 이런 프로젝트 구조가 불편해지기 시작했다.

 

더군다나 파일 업로드 및 다운로드 기능을 추가하려고 보니,

 

이 기능은 기존의 기능들과 너무나도 확실하게 분리되는 기능이라서

 

프로젝트 구조적으로도 확실히 분리시키고 싶었다.

 

---

 

그래서 이것저것 검색하며 알아보니,

 

• 모노리식
• 멀티 모듈 모노리식
• 멀티 모듈
• 멀티 모듈 msa

큰 구분으로는 이 정도로 프로젝트를 구분할 수 있을 거 같다.

 

기존의 모노리식으로는 개발을 매우 편하게 할 수 있지만, 편하다는 얘기는 곧,,

의존성을 쉽게 끌어다 쓰고 있다는 얘기가 될 수 있다. 높은 확률로 갈수록 의존성이 복잡해지는 구조가 된다.

 

그렇다고 msa 를 하자니,, 마이크로 서비스 간의 동기화 문제, 네트워크 문제, 등 오버헤드가 너무 많았다.

 

내가 유지 보수하고 있는 웹서비스는 회원이 아직 200명도 안되는 작은 동아리일 뿐이고,,

 

예산이 그렇게 많지 않기 때문에, 마이크로 서비스를 운영할 만큼 성능 좋은 기반시설(aws 이나 동아리 제공 물리 서버) 을 이용할 수 없다.

 

어찌저찌 모듈로 나누어서, 멀티모듈을 하든, 멀티모듈 모노리식 둘 중 하나를 한다고 치고, 프로젝트 구조를 변경해보기로 했다. 

(모노리식은 일단 벗어나보기로 했다. 서비스간 의존성을 줄이는 연습이기도 하고, 하나의 서비스를 변경했을 때, 프로젝트 전체를 빌드하는 것이 아니라 특정 서비스만 빌드함으로써, 개발 주기 속도도 높일 수 있을거라고 생각했기 때문이다.)

 

 

근데 고민을 해보니

 

결국은!!

 

멀티모듈이든, 단일 모듈 모노리식 이든,,

 

프로젝트 구성은 비슷해야 한다는 걸 깨달았다.

 

도메인을 중심으로, 응집과 결합을 잘 구분하게 되면 자연스럽게 프로젝트가 구성되게 되고,

 

이것을 바탕으로, 모듈을 여러개로 나누든, 하나로 하든, msa 를 하든,, 그렇게 진행되는 것이었다.

---

 

그래서 기존에 있던 프로젝트를 ddd 의 철학에 맞게 다시 재구성하기 위해

 

이런 저런 책을 수집하게 되었는데, 그 중 하나가 "도메인 주도 설계 철저 입문" 이라는 책이다.

 

초중반부까지의 내용은 개발하다보니 자연스럽게 습득한 개념들이 많지만,

 

바운디드 컨텍스트, 어그리게이션 등의 개념을 보니,

 

"프로젝트 리팩토링을 더 해야겠구나..." 라는 생각이 들면서,,

 

서비스 간의 통신은 어떻게 할지.. 등등의 고민이 많아졌다.

 

api 엔드포인트로 할지 메세지큐를 이용할지,,,? 그런 고민? 물론 서비스의 특성마다 달라지겠지? 호호