도메인 주도 설계 - Bounded Context

Bounded Context란 업무를 구분해 놓은 것에 불과합니다. 이 컨텍스트 내부가 하나의 문제의 도메인이 되지요. 하지만, 이 경계를 어떻게 만드느냐에 따라 전체적인 아키텍처가 구성에 큰 틀을 제공하기도 합니다. 예를 들어 기업에 있어 인사/영업/마케팅/회계 등의 시스템이 있을 경우 이것을 하나의 Bounded Context로 볼 수 있고 이 내부가 하나의 도메인이 되게 됩니다. 만약 더 세부적인 컨텍스트로 나눌 수 있다면 더 작은 컨텍스트가 될 수도 있고요. 인사의 경우 급여관리, 직원관리 등의 작은 Bounded Context가 될 수 있다는 뜻이죠. 또 다른 예를 하나 들어보면 온라인 쇼핑몰이 있겠습니다. 쇼핑몰은 크게 상품, 판매, 결제 등으로 경계를 나눌 수 있게 되는데, 이 하나 하나가 결국은 도메인이 될 수도 있고 더 작게 나눠야 도메인이 될 수도 있습니다.

 

 

도메인 주도 설계를 하다보면 마이크로 서비스 아키텍처 얘기가 자주 나옵니다. 우리 시스템을 도메인 주도 설계로 구현한다면 어떻게 마이크로 서비스로 구성할까 고민들을 많이 하실겁니다. 마이크로 서비스란 각 문제의 도메인 또는 Bounded Context를 얼마나 작게 쪼게느냐에 달려 있습니다. 기업의 사이즈가 작으면 인사/영업/회계 등 모든 기능을 하나에 때려 넣어도 무방합니다. 50인 정도가 사용하는 시스템이 각각 모든 것이 분리되어 있다는 것은 개발과 유지보수에 더 많은 리소스가 투자되고 효율도 좋지 못합니다. 제가 장담하건데, 왠만한 개발자 분들은 이미 마이크로 서비스를 경험하고 구현하고 있다고 봐도 무방합니다. 어느정도 규모가 되는 기업들은 모든 시스템이 분리되어 있기 때문이죠. 한 회사의 모든 시스템을 하나에 때려 넣는 프로젝트는 저의 경험 상 존재하지 않습니다. 여러분들도 그러시죠? 그러니까 이미 마이크로 서비스를 다 사용하고 계신겁니다.

위의 예를 조금 더 현실화 시켜 보도록하겠습니다. 지금 온라인 쇼핑몰을 구축하는데 상품 10개만 파는 아주 작은 쇼핑몰을 구현하려고 합니다. 한정된 상품만 팔려고 하기 때문에 주문이 들어오면 주문 내역 확인해서 배송만 보내주면 됩니다.이럴 경우 상품 관리라는 것도 필요 없고, 판매 사이트와 결제 기능만 있으면 모든 것이 완료될 수 있습니다. 그럼 판매와 결제가 커다란 Bounded Context가 될껍니다. 사실 온라인 결제 시스템을 이 사이트를 위해 개발한다면 배보다 배꼽이 더 커지므로 우리는 Paypal같은 이미 운영되는 결제 서비스를 이용하려고 합니다. 그러면 이 두가지 영역이 이미 Bounded Context이고 마이크로 서비스로 구현이 되는 것입니다. 우리는 판매 기능만 제공하는 부분을 개발하고, 결제는 다른 시스템을 이용하고. 모든 기능을 다 개발할 수도 있고, 이미 제공되는 서비스를 메쉬업 시켜서 서비스를 구현할 수도 있습니다. 마이크로 서비스라고해서 거창한 것이 있는 것이 아닙니다. 처음에는 10개 상품만 팔았는데, 수익이 나기 시작하고 상품을 더 판매하고 싶고 배송 시스템과도 연계를 하고 싶습니다. 그러면 상품 관리와 배송이라는 2개의 Bounded Context가 새로 추가되는 것이고, 각각의 마이크로 서비스가 될 수 있는 것이죠. 배송 시스템도 Paypal과 같이 배송업체의 API를 이용하게 되면 우리는 상품 관리 도메인만 추가로 개발하면 되는 것입니다.

하지만, 우리 시스템은 아직도 작습니다. 개발자가 3명에 QA가 1명이라면 판매와 상품 관리를 마이크로 서비스 형태로 구현해서 서로 통신을 하게끔 해야 할까요? 그렇게 되면 관리가 용이하지 않을 뿐더러 관리가 더 힘들어집니다. 이럴 경우에는 그냥 Monolithic 아키텍처를 사용하는 것이 낫습니다. 하지만, 향후를 위해 자바의 경우 패키지나 모듈로 따로 관리하는 것이 좋고, C#의 경우는 개별 프로젝트로 관리하는 것이 좋습니다. 그러다가 시스템이 점점 커지고 개발자가 계속 충원된다면 그 때 마이크로 서비스로 분리를 해도 늦지 않을 것입니다.

Bounded Context를 마이크로 서비스로 구현하는 것은 도메인 영억의 깊이와 넓이, 그리고 개발팀의 구성원 수와 역량에 따라 가야지, 아... 이건 하나의 Bounded Context로 구분된 도메인이니까 무조건 마이크로 서비스로 개발해야 한다고 생각하는 거은 틀린 접근 방법일 수도 있습니다.

제가 지금까지 경험하기로는 하나의 마이크로 서비스로 도메인을 개발하려면 개발자가 5-8명, BA와 QA가 각각 1명, 그래서 토탈 10명 이내가 하나의 마이크로 서비스로 구현하기 적당한 것 같습니다. 그래야 개발에 있어서도 역시 중요한 소통이 원활하기 때문입니다. Bounded Context는 비즈니스가 진화할 수록 더욱 세분화되는 것이고 실제 분리가 일어날 때, 원할하게 Legacy와 통합할 수 있도록 구현해 놓는 것이 좋은 방법입니다.