Cabi 서비스의 스프링 포팅과 DDD

 

아래 글은 이전에 작성해놓은 글입니다.

대략적인 상황은, 저희 서비스에서, 기존의 Nestjs를 사용하던 백엔드가 자바 스프링으로 포팅하는 과정에서, DDD(도메인 주도 설계)방식을 적용하기로 한 지점에서 제가 느낀 부분들을 정리하고 팀원분들과 공유하였던 글입니다.

---

Cabi 서비스에 과연 DDD는 필요한 것인가

현재 스프링 포팅 진행을 위해 준비를 하면서 저희는 DDD를 적용하여 재설계 해보기로 했고, 서로 책도 읽고, 탐구도 하면서 스터디를 진행한 상황입니다. 하지만, 더 공부할 수록 저는 근본적으로 저희가 굳이 DDD를 적용해야 하는지에 대한 의구심이 생기고 있습니다.

 

DDD를 적용하는 대개의 케이스들은, 미리 어떠한 프로젝트나 프로그램, 서비스를 구성하기 이전에 설계를 하는 것이 아닌, 이미 서비스의 복잡도가 높아져 있거나, 해결하고자 하는 문제 영역에 대한 소프트웨어적 구현(코드)부들이 결합도(Coupling)가 높은 경우, 더 나은 구조를 도입하여 서비스의 복잡도를 낮추고, 응집력(Cohesion)을 높이고자 사용하는 케이스들이라고 생각합니다. 혹은 이미 도메인 별로 잘 나누어 모듈화를 해놓은 코드들에서도 증가하는 요구사항들에 맞추어서 복잡도가 증가한 경우에, DDD를 이용하여 더 명확한 재설계를 하고자 하는 경우에 사용한다고 생각합니다. 그리고 이러한 복잡도나, 트래픽을 받아내는 등의 서비스 적인 측면에서 장애가 잦은 경우에는 비용을 고려하여 별도의 도메인 별로 서버를 구현한 MSA로 넘어가게 되는 것으로 생각하고 있습니다.

 

저희는 포팅을 하면서 기존의 아쉬웠던 부분들을 리팩터링하고, 추후의 유지보수성을 높이고자 한다고 생각합니다. 그리고 그것의 중점에 DDD를 둔 것이고요. 하지만, 근본적으로 서비스 자체의 복잡도가 높지 않다는 점에서, 꼭 DDD만으로 포팅을 진행한다기 보다는 다른 패턴들을 이용해서 ‘리팩터링’이라는 관점은 충분히 해소될 수 있을 것이라고 생각이 듭니다. 요약하자면, 걸맞지 않는 옷을 입히려고 하는 것이라는 생각이 들었습니다.

 

과연 우리가 스프링 포팅을 하는 데에 DDD를 기준으로 해야하는지, 할 수는 있는 것인지에 대한 의문들을 정리해보았습니다. 현재 우리의 cabi 서비스는 복잡하고 큰 서비스가 아니라고 생각합니다. 따라서 위의 이유들을 미루어보아 생각했을 때에는 DDD를 적용하기에는 적절하지 않다고 생각합니다. 하지만, 우리는 배우는 학생들의 입장이고 서비스에 DDD를 얼마든 적용할 여지는 있다고 생각합니다.

만약 필요하다면 어떻게 구성할 것이고, 왜 그렇게 하고자 하는 것인가

지금부터는 DDD를 적용을 한다는 것을 전제로하고 써보겠습니다.

제가 생각하는 DDD를 포팅과 동시에 현재 서비스에 적용하고자 하는 이유는 다음과 같습니다.

- 우리는 DDD를 경험해보고자 한다 (설계 - 구현)
- 현재의 코드들을 더 나은 관점을 기준으로 리팩터링하고, 근본적으로 서비스의 유지보수성과 요구사항들에 대한 대응가능성을 높이고자 한다

위는 우리 서비스가 DDD를 왜 써야 하는지에 대한 저의 생각이었고, 다음은 제가 생각하는 DDD가 갖는 근본적인 의의입니다.

- 관심사의 분리가 도메인이라는 기준으로 이뤄져서, 서비스의 유지 보수성과 변화에 대한 유연성을 높일 수 있어야 한다.
- 함께 공유, 이해되는 관심사와, 그 영역에서 사용되는 언어들의 의미에 대한 상호 통일성이 유지되어 서로 명확하게 이해할 수 있어야 한다.

상술했듯이, 우리 서비스는 복잡하지 않습니다. 이러한 상황에서 DDD를 적용하여 설계를 하고자 한다는 것은, 단순히 현재의 서비스의 복잡도를 고려한다는 것 보다 앞으로의 요구사항들에 대한 대응 가능성을 더욱 높이는 것에 초점을 맞춰 결정한 것이라고 생각합니다. 그리고 이러한 경우에, 우리는 어떤 지점까지 가능성을 고려하여 설계할 것인지 고민해봐야 할 필요가 있습니다.

위 사항에서 ‘함께 공유, 이해되는 관심사’가 도메인이고, ‘그 영역에서 사용되는 언어’들이 유비쿼터스 언어이고, 하나의 유비쿼터스 언어가 다른 관심사마다 의미가 달라질 수 있고, 그 관심사들을 나누는 경계가 ‘바운디드 컨텍스트’라고 생각할 수 있을 것 같습니다.

’도메인, 유비쿼터스 언어, 바운디드 컨텍스트’와 같은 단어들은 모두 위에 적힌 이유(의미 공유와 통일성)를 위해 개념적으로 정의된 단어입니다. 이 단어들이 등장하는 이유는, 설계와 구현에 있어서 서로 인식하고 전달하는 의미의 뉘앙스를 명확하게 하기 위한 것입니다.

즉, 단순히 같이 일하고 개발하는 ‘우리’의 수준에서 서로 공유되는 정도가 아닌, 다른 사람들도 보고, 듣고, 이해할 수 있어야 한다는 것입니다. 여기서 ‘다른 사람’은 책에서 나타난 ‘이해관계자, 도메인 전문가’등이 있을 것이고, 더 나아가면 ‘이해관계자’는 사용자로도 생각해볼 수 있으며, 그렇다면 ‘개발을 모르는 사용자’로도 생각해볼 수 있을 것입니다.

서로 꾸준한 대화와 협의로 도메인을 나눠보고, 사용되는 용어들에 대한 정의해보고, 그것을 공유하는 이유는, ‘실제로 존재하는 문제 영역(도메인 모델)에 대한 더 깊은 탐구과 해결책을 세워보고 이를 해결 영역(코드 구현)으로 이끌기’를 더욱 원활히 하기 위함이고, 더 근본적인 이유는 위에 나타난 ‘유지 보수성과 변화 대응성’을 높이기 위한 것입니다.

 

위 사항을 고려해봤을 때, 우리의 설계는 다른 사람이 보더라도 이해가 잘 되어야 합니다. 그리고 그 설계 또한 이전에 정해놓은 기준점(유지보수성과 대응가능성)들을 고려했을 때, 구현 자체도 이해가 잘 되어야 하는 것이라고 생각합니다. 그 이유는, 우리는 cabi에 계속 머물러 있을 수 없으며, 새로운 팀원 또한 합류할 가능성이 있다는 것이고 이는 새로운 팀원도 이해할 수 있어야 한다는 것을 의미합니다. 또 더해서, 넓은 가능성을 고려한다면, 단순히 42 서울뿐만이 아닌 42 경산, 혹은 42 커뮤니티가 아닌 다른 이해관계자들의 요구사항에 대처해야할 수 있다는 점도 고려해야하기 때문에, 설계와 구현 모두 다른 사람이 이해할 수 있게끔 해내야 한다고 생각합니다. 따라서 우리는, DDD를 적용할 때 엄격한 기준을 설정하여 적용해야 한다고 생각합니다.

 

하지만 엄격한 기준을 찾는 것은 어렵다고 생각합니다. 제 생각에 DDD라는 것은 정론이 없으며, 각자의 생각이 개입할 여지가 많고, 여러가지 환경들에 영향을 받는 방법이기 때문입니다. 단순히 레퍼런스와 몇 가지 참고 자료들을 이용해서 기준점을 설정할 수 있습니다. 하지만, 정론이 없다는 것은, 저희가 이해한 의미를 바탕으로 설계할 수 있음을 의미한다고 생각합니다. 더 나아가서 저는, 단순히 레퍼런스를 참고하여 적용한다기 보다는 레퍼런스들을 분석하여 우리의 생각대로, 우리 서비스에 알맞게 구현하고, 그 과정에서 왜 그렇게 했는지 이유를 명확히 하는 것이 더 좋은 방법이 될 것이라고 생각합니다. 레퍼런스를 빨리 찾고, 적용하는 것도 프로그래머의 능력이지만 제 생각에 더욱 중요한 것은, 그 레퍼런스들을 보고 자신만의 규칙과 방법론을 세우는 것이 더 중요한 역량이라고 생각하기 때문입니다. 따라서 ‘엄격한 기준’은 저희가 세워야 하는 것이라 생각하고, 이런 상황에서 제가 생각한 ‘엄격한 기준’은 무엇인지 대략적으로 설명해보겠습니다.

- 우리는 새로운 팀원이 봐도 이해할 수 있는 코드와 설계를 작성해야 한다. → 코드의 가독성을 중요시 해야한다
- 우리는 앞으로 우리의 서비스가 매우 복잡해질 것이라고 생각하고 설계해야 한다. → 설계를 할 때, 왜 이렇게 설계해야 하는지에 대한 이해가 명확해야 한다
- 우리의 설계와 구현을 이용하여 다른 42, 또는 외부에서도 템플릿 처럼 적용가능할 수 있어야 한다. → 사실상 MSA로 찢기 직전이라고 생각하는 것도 한 방법이 될 수 있을 것 같다

아마 차후에 더 추가되거나 진행되면서 달라질 수 있을 것 같습니다. 또한 이 모든 것들이 만족될 것이라고 생각하지는 않습니다.

하지만, 이러한 기준점들을 가지고 현재의 설계와 구현이 진행되는 동안의 서로 간의 합의점을 찾을 수 있지 않을까라는 생각을 해봤습니다.

경험하고자 하는 바

위에서 상술한 ‘엄격한(혹은 엄격하지 않더라도) 기준’을 각자 설정하고, 공유할 수 있으면 좋겠습니다. 그리고 더욱 근본적으로 우리가 포팅을 진행하면서 DDD를 기준점으로 설정해놓은 이유에 대해 명확하게 인지하면 좋겠습니다.

그리고 가장 중요하게 생각하는 지점은, DDD를 적용하기로 한 이상 이번 포팅과 설계를 통해서, DDD에서 사용되는 개념과 DDD를 사용하는 이유와 지점에 대해 잘 이해하고 본인만의 설계 방식을 정립해서 같이 진행하는 저희 모두에게 큰 도움이 되었으면 좋겠습니다.