마이크로서비스 : 전략적 설계 : 바운디드컨텍스와 유비쿼터스 : 개념, 정의, 개요

도메인 주도 설계

소프트웨어에서 효과적인 설계는 매우 중요합니다. 도메인 주도 설계에서는 설계를 효과적으로 수행할 수 있도록 마이크로서비스를 식별해내는 전략적 설계와 식별된 마이크로서비스의 내부를 상세히 설계하는 전술적 설계로 설계를 두 개의 단계로 설명하고 있습니다. 상세한 설계에 들어가기에 앞서 전략적 설계를 수행합니다. 전략적 설계는 마이크로서비스 도출을 위해서 비즈니스 상 전략적으로 중요한 것을 찾아 중요도에 따라 이를 나누는 방법을 설명하고 있습니다.

 

 

전략적 설계

이런 전략적 설계를 수행하기 위해 중요한 두 가지가 있는데, 첫 번째는 도메인의 주요 개념을 정의하고 도메인 간의 경계를 식별하는 Bounded Context가 있습니다. 그리고 두 번째는 프로젝트를 수행하는 모든 팀원이 공통으로 사용하는 유비쿼터스 언어가 있습니다. 

에자일 프로젝트 관리 시스템을 개발하는 프로젝트를 수행하는 경우를 예로 들어보겠습니다. 설계 초기 프로젝트의 각 팀은 프로젝트의 핵심이 되는 부분을 설계하기 시작합니다.

프로젝트 팀은 계속해서 도메인을 분석하면서, 이해하면서 필요한 개념들을 추가하게 됩니다. 이렇게 계속해서 많은 내용이 추가되고 또 추가된 내용을 위해 또 다른 내용들이 계속 추가가 됩니다. 어느 순간 처음 핵심이 되는 부분을 설계하는 것으로 시작했던 것이 큰 하나의 덩어리로 만들어지게 되었습니다.

이런 것들을 큰 진흙 공이라고 표현을 하는데 이 진흙 공 안의 모델을 보니 모델 안에 너무 많은 개념들이 포함되어 있고, 또 모델 내에 언어가 모여 있는 것을 확인할 수 있습니다. 이렇게 큰 한 덩어리의 모델은 기능의 추가나 개선, 테스트와 유지보수를 어렵게 만드는 문제점을 갖고 있습니다.

이런 거대하고 복잡한 개념들 속에서 문제되는 영역을 쉽게 이해할 수 있습니다. 전체 비즈니스 도메인을 논리적으로 구분될 수 있는 개념들로 분류해서 나눠줘야 합니다. 즉, 많은 개념들이 하나로 엮인 복잡한 모델은 전체의 비즈니스 도메인을 하나의 논리적인 하위 영역으로 분리해야 한다는 것입니다. 이렇게 전체의 큰 도메인을 분리한 것을 서브도메인이라고 합니다.

서브도메인은 핵심 서브도메인, 지원 서브도메인 그리고 일반 서브도메인의 총 세 가지 유형으로 구분이 됩니다. 서브도메인의 유형 중 첫 번째인 핵심 서브도메인은 다른 경쟁자와 차별화를 만들 수 있는 비즈니스 영역이기 때문에 기업의 프로젝트 목록에서 높은 우선순위를 가집니다. 소프트웨어 개발에 있어서 전략적으로 가장 큰 투자가 필요한 곳에 해당됩니다.

두 번째, 지원 서브도메인은 어느 정도 비즈니스에 필수적이지만, 핵심은 아닌 부분으로 볼 수 있습니다. 그러나 지원 서브도메인 없이는 핵심 도메인을 성공시킬 수 없습니다. 따라서, 핵심 서브도메인 다음으로 중요한 영역입니다.

마지막으로 일반 서브도메인은 비즈니스적으로 특화된 부분은 아니지만, 전체 비즈니스 솔루션에 필요한 부분으로
기존 제품의 구매 또는 핵심이나 지원 서브도메인이 할당된 팀에서 직접 구현하여 적용할 수 있습니다. 이렇게 거대한 전체 비즈니스 도메인을 핵심 서브도메인, 지원 서브도메인, 일반 서브도메인으로 분리합니다.

 

 

이렇게 서브도메인을 식별하는 과정을 통해 프로젝트에서는 비즈니스의 핵심 영역을 찾을 수 있고 또 각 핵심, 지원, 일반 서브도메인 간의 관계를 이해할 수 있게 됩니다.

 

 

바운디드 컨텍스트

Bounded Context는 이름의 뜻과 같이 의미적으로 동일한 맥락의 경계 또는 범위를 표현하는 것입니다. 또 다른 중요한 도구인 유비쿼터스 언어로 모델링 되는 것이 가장 중요합니다. 의미적으로 동일한 맥락의 경계라는 것은 그 범주 내에서 소프트웨어 모델의 각 컴포넌트가 특정한 의미를 갖고 그 특정한 일을 한다는 것을 의미하게 됩니다.

Bounded Context는 모델이 구현되는 곳이고, Bounded Context마다 각각 분리된 소프트웨어의 산출물이 나오게 됩니다. 일반적으로 서브도메인은 Bounded Context와 매핑이 됩니다. 하나의 서브도메인은 하나의 Bounded Context를 갖는 일대일 관계를 갖도록 하고 있습니다. 이것은 Bounded Context의 명확한 개념과 모델을 잘 유지할 수 있도록 하기 위함입니다.

실제 많은 프로젝트에서는 그림의 지원 서브도메인처럼 하나 이상의 Bounded Context가 정의될 수 있습니다. 프로젝트를 진행하면서 발생할 수 있는 문제점 중 하나는 팀 내 소통에 대한 것이 있습니다. 프로젝트 진행 중에 제품 책임자와 도메인 전문가 그리고 소프트웨어 개발자 간의 의견은 프로젝트 진행 중에 발생되는 큰 문제점 중에 하나입니다.

동일한 의미를 표현하는 서로 다른 용어로 인해 실제 업무에서 사용하는 고객의 용어를 도메인 전문가와 개발자가 기술적인 언어로 이해하고 표현하는 문제입니다. 도메인 전문가의 잘 만들어진 도메인 모델이 개발자에게 다른 의미로 전달되는 문제, 이런 문제들을 해결하기 위한 번역 작업이 필요하게 되는 문제가 있게 되는 것입니다.

 

 

도메인 주도 설계

도메인 주도 설계는 생각하는 방식이 사용하는 언어에 반영된다는 말처럼 프로그램이 직접적으로 도메인 개념을 표현할 수 있도록 하는 방식입니다. 애플리케이션을 직접 개발하지 않는 사람도 도메인 계층 내의 순수 도메인 모델의 내용을 보고 애플리케이션이 표현하는 도메인을 쉽게 이해하고 수정이나 확장할 수 있어야 한다는 것을 말합니다.

유비쿼터스 언어는 사용자와 도메인을 이해하기 위해 의사소통할 때와 설계 모델링을 진행할 때 또는 구현할 때 소스의 class명, method명에도 사용되어야 하는 언어입니다. 따라서 유비쿼터스 언어가 도메인의 의도를 정확히 반영하고 도메인의 핵심 개념이 잘 표현될 수 있도록 정의되어야 합니다. 도메인 전문가와 소프트웨어 개발자 간 이견과 오해의 문제는 유비쿼터스 언어를 사용함으로써 해결을 할 수 있습니다.

 

 

유비쿼터스 언어

쇼핑몰 소프트웨어의 Bounded Context가 Sales, Accounting, Order. 세 개로 정의되어 있습니다. 과거에 Customer의 개념은 쇼핑몰을 사용하는 사람으로서 관심 품목과 필요한 품목, 결제수단과 배송을 위한 주소 등의 연락처 정보 그리고 이런 구매와 관련된 그동안의 내역의 개념들을 모두 담아 Customer라는 데이터베이스라는 생성해서 저장을 했습니다.

그러나 이런 Customer라는 개념은 각각의 Bounded Context를 담당하는 조직별로 서로 다른 정의를 가질 수가 있습니다. 이런 경우 각 Bounded Context에서는 통합해서 사용하던 Customer를 명확한 용어로 재정의해서 사용을 해야 합니다. 따라서 유비쿼터스 언어가 도메인의 의도를 정확히 반영하고 도메인의 핵심 개념이 잘 표현될 수 있도록 정의해야 됩니다.

이런 내용을 바탕으로 Bounded Context를 보면 Sales Context에서 Customer는 Buyer로, Accounting Context에서는 Customer가 Payer로, Order Context에서는 Customer가 Receiver로 정의돼서 사용을 해야 됩니다.

도메인 주도 설계에서는 서로 다른 개념들을 각기 다른 Bounded Context 내부로 분리를 해놓으면서 개념 간 차이를 더욱 중요시하게 됩니다. 이렇게 정의된 개념들은 각각의 Bounded Context 안, 즉 Bounded Context를 소유하는 팀의 공통의 언어, 즉 유비쿼터스 언어가 됩니다.