<div id="readability-page-1" class="page"><article><div><p>이제는 꽤나 대중적인 방법론으로 자리 잡은 DDD(domain driven design)는 도메인을 중심으로 소프트웨어를 모델링하는 데 중점을 둔 설계 접근 방식입니다.</p>
<p>저는&nbsp;DDD가 이전의&nbsp;방법론들과 크게 다르지 않다고 생각합니다. 그간의&nbsp;설계 방식은 개발하고자 하는 서비스의 역할과 책임을 명확히 규정해&nbsp;개발과 유지 보수 관점에서의&nbsp;편의를 얻을 수 있게끔&nbsp;발전해 왔는데요.&nbsp;DDD 또한 이 맥락에서 크게 다르지 않게&nbsp;서비스의&nbsp;역할과 책임을 어떻게 잘 정의할 수 있는지&nbsp;구체적인 방안을 제시한 방법론이라고 생각합니다. &nbsp;</p>
<p>ABC Studio의 개발 팀은 DDD를 활용해 소매 상품 판매를 위한 새로운 Merchant 시스템을 론칭했습니다. 흔히 DDD를 활용해&nbsp;개발할 때 이를 어떻게 구현할지에&nbsp;집중하는 모습을 볼 수 있는데요. 이와 다르게 저는 이 시스템을 론칭하는 과정에서 구현이&nbsp;크게 중요한 부분이 아니라고 느꼈습니다.</p>
<p>저는 ABC Studio에서&nbsp;백엔드를 담당하고 있는 김민섭이고, 이 글을 통해&nbsp;DDD를 활용해 새로운 Merchant 시스템을&nbsp;개발한 과정과 느낀 점을&nbsp;공유하고자 합니다.</p>

<p>본격적으로 DDD를 활용한 과정을 다루기에 앞서 새로운 Merchant 시스템이 어떤 시스템인지 이해할 필요가 있습니다.&nbsp;</p>
<p>기존 시스템은 주로 음식 배달 서비스를 위한 시스템으로, 저희는 이를 기반으로 소매 상품 판매 서비스도 전개하고 있었는데요. 그렇다 보니&nbsp;소매 상품 판매에 적합한 형태로 서비스를&nbsp;구성하지 못하고 소위 ‘휴지를 파는 음식점’의 형태로 판매가 이뤄져 왔습니다. 이와 같은 문제 때문에 서비스하면서 여러 한계에 봉착했고, 이를 개선하기 위해 기존 시스템과 독립적인 Merchant 시스템을 개발하기 시작했습니다.</p>
<p>새로운 Merchant 시스템의 특징은&nbsp;소매 상품 판매에 특화된 플랫폼으로 기획해서 기존 시스템의 서비스에서뿐&nbsp;아니라 다른&nbsp;서비스의&nbsp;판매 면에서도 물건을 판매할 수 있도록&nbsp;설계했다는 것입니다.</p>
<p>구체적으로 말씀드리자면, Merchant 시스템에서는 점포와&nbsp;상품, 재고 등&nbsp;소매 상품 판매에 필요한 정보를 제공하고,&nbsp;각&nbsp;판매 면에서는&nbsp;이 정보를 전달받아 사용자에게 판매를 진행하는 구조입니다. 판매 면에서 상품이 판매되면 해당 주문 정보는 Merchant 시스템으로 전달되고, Merchant 시스템은&nbsp;이를 점포에 전달해서 상품을 준비해 사용자에게 배달할 수 있게끔 주문을 제어한 뒤 그 상태를 다시 해당 서비스의 판매 면으로 전달합니다.&nbsp;</p>
<p>Merchant 시스템&nbsp;내부에서는 판매 면을 '소비자 플랫폼(Consumer Platform)'이라고 정의했는데요. 아래와 같이 Merchant 시스템에서 소비자 플랫폼에게 점포나 상품과 같은 판매에 필요한 정보를 제공하면, 소비자 플랫폼에서는 이 정보를 바탕으로 사용자에게 상품을 전시하고 판매합니다.&nbsp;</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/d4cd878ae3bc4da79d257d5baae5e155.png?updatedAt=1753417974000" width="700" height="auto" alt="Merchant 시스템 판매 흐름"></p>
<p>소비자 플랫폼에서 판매된 주문 정보는 Merchant 시스템으로 전달되고, Merchant 시스템은 이를 다시 점포와 배달원에게 전달해 사용자에게 상품이 배달되도록 합니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/111374d0e530408081554b94735c2d2c.png?updatedAt=1753418008000" width="1000" height="auto" alt="Merchant 시스템 배송 흐름"></p>
<h2 id="minseobkimDDD의Merchant시스템활용사례에대해서-도메인정의">도메인 정의</h2>
<p>앞서 설명한 바와 같이 Merchant 시스템은&nbsp;상품 판매에 필요한 정보 생성 및 제공까지만 담당하고, 이후 실제로 소비자에게 판매하는 영역은 소비자 플랫폼으로 위임합니다. 그렇기 때문에 일반적인 전자 상거래에서 정의하는 도메인의 상당 부분을 덜어내고, 상품을 판매하기 위한 핵심/공통&nbsp;정보만을 다루는 범위로 도메인을 정의하고자 했습니다.</p>
<p>프로젝트&nbsp;초기에는 쿠폰이나 할인 등을 다루는 프로모션 도메인도 이 시스템에 포함되기도 했는데요. 어떤 부분을 위임하고 어떤 부분을&nbsp;담당하는 것이 효율적일지&nbsp;많은 논의를 거친 끝에 다음 다섯 가지 도메인으로 Merchant 시스템의 영역이 정의됐습니다.&nbsp;</p>
<ul><li>점포(shop)</li><li>상품(item)</li><li>카테고리(category)</li><li>재고(inventory)</li><li>주문(order)</li></ul>
<h2 id="minseobkimDDD의Merchant시스템활용사례에대해서-DDD를활용한서비스구성">DDD를 활용한 서비스 구성</h2>
<p>아래 그림은 DDD를 활용해 서비스의 각 시스템을 구성하는 시스템 아키텍처부터 전체 서비스 아키텍처를 구성한 과정을 간략하게 나타낸 그림입니다.&nbsp;</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/4353a352aba04b129151bfec26e4d337.png?updatedAt=1753418079000" width="1000" height="auto" alt="전체 서비스 아키텍처"></p>
<p>각 부분이 어떤 과정을 거치며 위와 같이 발전해 나갔는지 살펴보겠습니다.</p>
<h3 id="minseobkimDDD의Merchant시스템활용사례에대해서-시스템아키텍처구성">시스템 아키텍처 구성</h3>
<p>시스템을 구현하는 개발 아키텍처는 클린 아키텍처를 따르도록&nbsp;구현했습니다.&nbsp;</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/37840cce836e4da5aecc8944db7b07d9.png?updatedAt=1753418126000" width="1000" height="auto" alt="Merchant 시스템 아키텍처"></p>
<p>'왜 클린 아키텍처를&nbsp;따랐냐'고 물어보신다면 따라 할 때 참고할 수 있는&nbsp;책이 얇았기 때문입니다. 🙂 물론&nbsp;반 농담 삼아서 이야기한 것인데요. 나머지 반의 관점에서는 실제로 이 점이 중요했습니다. 우리 모두가 DDD의 전문가는 아니며,&nbsp;앞으로 새로 합류할 인원 또한 그렇지 않을 가능성이 높습니다. 따라서&nbsp;시스템을 구현하는 방법은 모두가 쉽게 이해하고 따를 수 있는 방법이어야 하는데요. 얇은 책 한 권을 읽고 따라 할 수 있다는 것은 클린 아키텍처를 선택하게 만든 주요 장점 중 하나였습니다.</p>
<p>클린 아키텍처의 중심에는 도메인 엔티티가 있고, 도메인 엔티티에 접근할 수 있는 유스케이스를 통해 외부 인터페이스 어댑터를 구현합니다.&nbsp;여기서 중요한 점은, 클린 아키텍처에서 계층 간 의존성은 내부 방향으로만 허용하기 때문에 도메인 엔티티에서는 외부 환경에 영향을 주지 않고 도메인 코드를 모델링할 수 있다는 것입니다. 따라서 클린 아키텍처는 DDD를 적용하기에 적합한 아키텍처로 평가받고 있습니다.&nbsp;</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/f63f9358846f42fd943561996a906044.png?updatedAt=1753418148000" width="500" height="588" alt="클린 아키텍처"></p>
<h3 id="minseobkimDDD의Merchant시스템활용사례에대해서-시스템모듈구성">시스템 모듈 구성</h3>
<p>각&nbsp;도메인 서비스는&nbsp;각자의 역할에 맞춰 여러 개의 모듈로 구성해&nbsp;서비스합니다. 여기서 모듈은 크게 도메인의 비즈니스 로직을 처리하는 '엔진'과 외부&nbsp;요청을 받는 'API'로 구분됩니다.&nbsp;</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/0e90bb6dac1c4ffc9f2dd5d4958a712e.png?updatedAt=1753418169000" width="1000" height="auto" alt="Merchant 시스템 모듈"></p>
<p>이와 같이 구성한 이유는 시스템의 가용성과 확장성을 확보하고, 외부 시스템의 요청을 받는 부분과 도메인 로직을 처리하는 부분을 레이어로 분명히 구분해서 모듈 개발과 유지 보수 관점에서 편의를 얻기 위해서입니다.</p>
<p>API는 프로토콜의&nbsp;변화를 명확히 공유할 수 있도록 gRPC로 제공했고, API와 엔진 간&nbsp;요청 전달에는&nbsp;Apache Kafka를 이용했습니다. 또한 엔진 측에서는 Kafka의 작업 큐 라이브러리인 Decaton을 적극 사용해서&nbsp;파티션을 적게 사용하면서 처리량을 높였습니다.</p>
<p>흐름을 살펴보면, API로 들어온 요청은 내부 토픽을 통해 엔진으로 전달되며, 엔진은 전달받은 요청을 처리해 도메인 이벤트를 이벤트 토픽으로 발행해서 다시 이를 필요로 하는 외부 도메인으로 전달합니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/c2bc43e0a22d49e3bdac748655e20b5e.png?updatedAt=1753418200000" width="1000" height="auto" alt="Merchant 시스템 모듈 흐름"></p>
<p>각 도메인은 모두 위와 같은 구조를 동일하게 구현해 아래와 같은 구조로 외부에 서비스를 제공합니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/3dd54c29b6f04cb0a597a181392272bf.png?updatedAt=1753418226000" width="1000" height="auto" alt="Merchant 시스템 모듈 전체 흐름"></p>
<p>위 구조는 모든 구간이 비동기로 설계돼 있습니다. 따라서 전체 시스템이 빠른 API 응답 능력과&nbsp;요청한 작업이&nbsp;언젠가는&nbsp;처리될 것이라는&nbsp;<a href="https://ko.wikipedia.org/wiki/%EA%B6%81%EA%B7%B9%EC%A0%81_%EC%9D%BC%EA%B4%80%EC%84%B1" target="_blank">최종 일관성(eventual consistency)</a>을&nbsp;기대하는 경우에는 적합하지만,&nbsp;요청을&nbsp;즉각 처리해서&nbsp;그 결과를&nbsp;바로&nbsp;응답해야 하는 시스템에는 적합하지 않습니다. Merchant 시스템은 플랫폼으로 설계하고 있었기 때문에 많은 요청을 받아 빠르게 응답하는 능력이 우선 필요했으며, 대부분의 상황에서 도메인 작업을 즉각 처리하는 것은 필요하지 않았기에 위 구조를 사용할 수 있었습니다.</p>
<h3 id="minseobkimDDD의Merchant시스템활용사례에대해서-서비스아키텍처및팀구성">서비스 아키텍처 및 팀 구성</h3>
<p>소비자 플랫폼은&nbsp;일본 내&nbsp;서비스이기 때문에 일본&nbsp;팀과&nbsp;협업해야 했습니다. 협업은&nbsp;앞서 발행한&nbsp;<a href="https://techblog.lycorp.co.jp/ko/4-patterns-of-global-collaboration" target="_blank">글로벌 협업의 4가지 패턴</a>에서&nbsp;언급된 바와 같이 핵심 도메인&nbsp;개발은 한국의&nbsp;팀에서,&nbsp;현지&nbsp;시스템 연계는 일본의&nbsp;팀에서 담당하는 구조로 진행됐는데요. 한국 팀에서 생각하는 핵심 도메인의 역할과 책임을 일본 팀에게 공유하면서 핵심 도메인은 외부 환경에 영향을 받지 않아야 한다는 공감대를 형성하는 과정을 거쳤습니다. 이 과정을 통해 서로 확인한 역할에 따라 전체 서비스의 아키텍처를 대략 아래 그림과 같이 구성했습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/6534bc59278644dbaeaad23ced884382.png?updatedAt=1753418290000" width="1000" height="auto" alt="Merchant 시스템 서비스 아키텍처"></p>
<p>서로 공감대를 형성하는 과정에서 각 도메인의 역할이 조정되는 등의 결정 사항들이 도출되는데요. 저희는 이를 ADR(Architectural Decision Record)을 사용해 남겨뒀습니다.&nbsp;</p>
<p>ADR은 구축하려는 소프트웨어 아키텍처의 중요한 측면에서 내려진 결정을 기술하는 문서입니다. 이 문서를 작성한 이유는, 팀&nbsp;내에서 내린&nbsp;결정은&nbsp;별도&nbsp;문서로&nbsp;남기지&nbsp;않아도&nbsp;잘&nbsp;전달되는&nbsp;편이지만&nbsp;조직&nbsp;간에 논의해&nbsp;결정한&nbsp;사항들은 제대로 전달되지 않아 회의 후 시간이 지나면&nbsp;‘그때&nbsp;회의에서&nbsp;이렇게&nbsp;하는 것으로&nbsp;했던&nbsp;것&nbsp;같은데?’라고 생각하게 되는&nbsp;경우가&nbsp;많기 때문입니다. ADR에는&nbsp;딱히&nbsp;정해진&nbsp;규격이&nbsp;없기&nbsp;때문에 '어떠한&nbsp;논의를&nbsp;했고, 이 논의가&nbsp;왜&nbsp;필요했으며, 논의 끝에&nbsp;어떤&nbsp;결정을 했는지'를&nbsp;간략하게&nbsp;작성해&nbsp;문서로&nbsp;남겨두는&nbsp;것으로&nbsp;충분합니다.</p>
<p>서비스 아키텍처를 결정한 뒤에는 이에 따라 팀을 구성했습니다. 한국의&nbsp;팀은 핵심 도메인 개발을 담당하는 'Core 팀'으로 구성하고, 일본은 소비자 플랫폼과의 연계를 담당하는 'Link 팀', 앱과 관리자 기능을 위해 백엔드&nbsp;서비스를 제공하는 'BFF 팀', POS 연계를 위한 'Merchant Link 팀'으로 구성해&nbsp;각자의 도메인 역할에만 충실할 수 있도록 구성했습니다.</p>
<p>이와 같이&nbsp;각자의 역할을 명확히 정의한 후&nbsp;시스템을 구성하고,&nbsp;이에 맞게 아래와 같이&nbsp;팀을 조직해&nbsp;다른 도메인의 영역을 침범하는 실수를 줄였습니다.</p>
<p><img src="https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/dfde14cbd29b442aaab6300c4a135e48.png?updatedAt=1753418421000" width="650" height="auto" alt="Merchant 시스템 팀 구성"></p>
<h2 id="minseobkimDDD의Merchant시스템활용사례에대해서-마치며">마치며</h2>
<p>새로운 Merchant 시스템은&nbsp;위와 같은&nbsp;과정을 거쳐 예정된 시기에&nbsp;잘 론칭됐고, 현재까지&nbsp;별다른 문제 없이&nbsp;잘&nbsp;발전해 나가고 있습니다. 저는 이&nbsp;과정을 되짚어 보면서&nbsp;시스템 아키텍처와 모듈&nbsp;구성,&nbsp;전체 서비스 아키텍처 및&nbsp;팀의 모습이&nbsp;<a href="https://www.melconway.com/Home/Conways_Law.html" target="_blank">콘웨이의 법칙</a>과&nbsp;닮아 있다는 사실을 깨달았습니다. 전체의&nbsp;중심에 핵심 도메인이 자리하고, 핵심 도메인의 바깥에는 이를&nbsp;추상화하고 외부와 연계하는 계층이 존재해&nbsp;각자의 역할에만 충실할 수 있게끔 구성돼&nbsp;있다는 것입니다. 이와 같은&nbsp;구성 덕분에 처음에&nbsp;저희가&nbsp;의도한 바와 같이 여러&nbsp;다른 소비자 플랫폼이&nbsp;등장해도 핵심 도메인의 변화는 최소화되고 연계 계층에만 영향이&nbsp;미칩니다.</p>
<blockquote>
<p>콘웨이의 법칙</p>
<p>시스템을 설계하는 모든 조직은 그 조직의 소통 구조를 닮은 시스템을 설계할 것이다.</p>
</blockquote>
<p>흔히들 DDD에 대한 경험을 이야기해 보라고 하면 ‘헥사고날이&nbsp;…’로 시작해 기술 관점의 이야기만 공유되는&nbsp;경우가 많습니다. 하지만&nbsp;저희는 이번&nbsp;사례를 겪으면서 시스템 아키텍처와 같은 기술 관점의 경험도 중요하지만,&nbsp;도메인의 역할과 책임을&nbsp;논의해 결정한 뒤&nbsp;팀 간에&nbsp;공감대를&nbsp;형성해 이를 바탕으로 조직을 구성하는 것도 꼭 필요한&nbsp;의미 있는 경험이라고 느꼈습니다. 저희는 이 경험을 활용할 또 다른 도전을 기대하고 있는데요. 저희의 경험이 이 글을 읽고 계신 독자분들에게도 도움이 되기를 바라며 이만 마치겠습니다.&nbsp;&nbsp;</p></div></article></div>

LINE ENGINEERING

이제는 꽤나 대중적인 방법론으로 자리 잡은 DDD(domain driven design)는 도메인을 중심으로 소프트웨어를 모델링하는 데 중점을 둔 설계 접근 방식입니다.저는 DDD...

DDD를 Merchant 시스템 구축에 활용한 사례를 소개합니다

댓글