[마이크로서비스 아키텍처 : 패턴과 핵심 기술] MSA 분리 전략 - 도메인 주도 설계

도메인 주도 설계

 

분리할 서비스의 식별 전략

• MSA를 설계할 때 서비스를 어떻게 식별할 수 있는가?
• Art 영역 - 워크샵, 이벤트 스토밈ㅇ
• Science - 코드 의존성 분석, 데이터 의존성 분석 (기술적 측면)

 

 

 

서비스 분리와 도메인 주도 설계(DDD)

• DDD는 MSA의 서비스를 식별할 수 있는 도구를 제공한다
• DDD는 전략적 설계와 전술적 설계로 이루어져 있는데, 전략적 설계가 MSA의 서비스를 식별하는데 도움이 된다
• 그러나, DDD도 은탄환이 아니다
  • DDD를 사용한다고 Monolithic 서비스가 MSA로 완벽하게 적용 가능한 것은 아니다
  • 전략적 설계의 적용이 서비스의 올바른 식별을 보장하지는 않는다
  • DDD 또한 그저 서비스 식별을 도와주는 방법론/도구일 뿐이다

 

 

좋은 SW 개발을 위해서는

• 소프트웨어 개발
  • 복잡한 도메인에 관련된 문제들을 해결하여 사용자에게 가치를 제공하는 일이다
  • 여기서 도메인이란 보험, 은행, 커머스 등이 될 수 있다
  • 이러한 도메인은 계속해서 복잡해지고 있다
• 복잡한 도메인을 소프트웨어로 구현하기 위해서는 도메인에 대한 깊은 이해가 필수이다
• 따라서 도메인 전문가와 개발자 등의 구성원 모두가 도메인에 대한 깊은 이해와 합의를 위해 많은 노력이 필요하다

 

 

 

현실의 문제점

• 개발자
  • 도메인에 대한 이해보다는 다양한 기술 적용에 더 큰 관심이 필요하다
• 제품 책임자
  • 도메인보다는 일정, 비용 등에 더 많은 관심을 기울인다
• 개발자, 제품 책임자, 도메인 전문가의 의사소통의 어려움이 발생한다
  • 도메인에 대한 이해 정도 및 언어의 불일치가 발생한다
  • 이는 안좋은 SW 개발의 시발점이 될 수 있다

 

 

 

도메인이란?

• 해결해야 할 영역
• 소프트웨어를 개발하는 대상 영역
• 복잡한 비즈니스나 현실 세계의 문제가 된다
• Problem Space

 

 

 

도메인 주도 설계 개념

• 복잡한 현실세계의 문제를 해결할 좋은 SW를 만들기 위한 기법이자 철학
• 복잡한 현실 세계를 잘 이해하고 반영해서 좋은 SW를 만드는 것이 도메인 주도 설계의 철학이다
• 도메인 주도 설계는 도메인의 이해를 최우선시하는 모델링 기법이다
• 도메인 전문가와 개발자와의 커뮤니케이션을 강조한다
• 개발자가 구현하기 전에 도메인을 깊게 이해하는 것이 가장 중요하다
• 도메인과 도메인 모델 그리고 코드를 밀접하게 연관시키는 것이 중요하다
  • 언어를 통일시킴으로써 가능하게 할 수 있다
• 도메인 모델이란 도메인을 모든 사람이 동일한 관점에서 이해할 수 있고 공유할 수 있도록 단순화 시킨 것이다
  • Solution Space - Use Case Diagram, Class Diagram
• 코드에 도메인의 의미가 녹아있도록 구현한다
• 도메인 전문가들이 사용하는 언어를 코드와 도메인 모델에 잘 녹여내는 것이 도메인 주도 설계의 핵심이다!
• 도메인 주도 설계 정리
  • 크고 복잡한 도메인을 식별하고 깊게 이해한다
  • 이를 통해 발견된 다양한 도메인의 문제드을 해결하기 위해 소프트웨어 설계/개발 사상

 

 

 

Big Ball of Mud

• 처음에는 작게 설계를 시작한다
• 요구사항 추출 -> 분석 -> 설계 -> 구현

1단계

 

• 하지만 계속되는 추가 요구사항이 생긴다
• 결국 도메인은 복잡해지게 된다

2단계

 

• 복잡한 도메인에 대한 이해와 탐구가 부족한 상태에서 각각의 담당 업무와 관련된 내용을 계속 설계에 추가된다
• 요구사항은 계속 추가되고 이를 이해하지 않은 상태에서 계속하여 도메인에 내용이 추가된다
• 결국 중요한 것과 덜 중요한, 혹은 중요하지 않은 것들이 하나의 큰 덩어리로 얽히게 된다

 

• 이런 설계를 기반으로 구현된 코드는 많은 기능이 하나로 엮여 유지보수를 어렵게 한다
• 결국 각 클래스(엔티티)의 의미 파악이 어려워진다
• ex) User, Person, Member, Account ...

복잡한 도메인의 탄생

 

 

 

Big Ball of Mud 원인 by Vaughn Vernon

• 조직에서 SW 설계에 충분한 노력을 들이지 않음 -> 비용으로 인식
  • 요구사항이 추출되고 그게 설계로 넘어갈 때 각각의 이해관계자들이 제대로 된 이해 없이 설계를 진행하기 때문이다
  • SW 설계 자체를 비용으로 인식하고 빠른 설계 및 개발을 해야한다는 사고방식 때문이다
• 개발자는 도메인보다 기술에 너무 몰두하고, 많은 문제를 기술적으로만 해결하려고 한다 
  • 개발자는 도메인에 관심이 없다는 지적을 함
• 도메인의 이해 없이 개발자 상상 속의 추상화가 설계된다
  • 따라서 개발자와 도메인의 언어가 달라지게 된다
  • 개발자의 네이밍을 도메인 전문가가 이해하지 못할 수도 있다
  • 즉, 도메인 전문가의 언어와 개발자의 언어가 매칭이 안된다
• 도메인 전문가의 멘탈 모델과 실제 구현체 사이에 큰 차이를 야기한다

 

 

 

도메인 주도 설계

• 기존 SW가 Big Ball of Mud SW일 때, 이를 비즈니스 상 중요도에 따라 도메인으로 구분할 수 있다
• 경계가 구분된 도메인을 하나씩 해결해 나가는 방법이다
• 도메인 주도 설계의 가장 중요 포인트!
• => 도메인 전문가와 엔지니어가 함께 참여하는 반복적인 커뮤니케이션을 통해 도메인에 대한 공통의 언어를 구축하는 것

 

 

 

언어? 설계?

• 도메인 주도 설계의 목적은 도메인 전문가의 비즈니스 관점에서의 언어가 설계 모델 뿐만 아니라 코드에도 그대로 반영되는 것이다
• 도메인의 탐색과 공통 언어의 구축 작업이 곧 설계 작업이 된다

 

 

 

어떻게 도메인 탐색, 언어 구축 하는가?

도메인 탐색 및 설계 과정

• 한 번에 도메인 탐색 및 설계는 불가능하므로, 반복적인 커뮤니케이션이 중요하다
• 워크샵은 커뮤니케이션의 좋은 도구가 될 수 있다
• 티타임, 식사, 회의 등 최대한 도메인 전문가와 개발자가 자주 커뮤니케이션하고 문서화해야 한다
• 아래는 Vaughn Vernon의 개인적인 생각이지만, 중요한 것은 꾸준한 커뮤니케이션이다

개발자들이여 제발 도메인 전문가 좀 찾아가세요
by Vaughn Vernon

 

• 도메인은 만들어서 설계하기 보다는 이미 있는 것을 탐색하고 식별해내는 것이다
• 반복적인 탐색 과정을 통해 도메인 모델을 정제해 나가야 비로소 정확한 모델 식별이 가능하다
• 처음부터 완벽한 모델을 얻는 것은 불가능에 가깝다
• 처음 식별된 도메인은 특릴 확률이 크다는 가정하에 일을 진행하면서 반복적으로 재검토, 개선해 나가야 한다
• 이러한 반복적인 과정 자체가 중요하다!

 

 

 

워크샵

• 유비쿼터스 언어를 정의하고 서브도메인을 식별하기 위해서는 워크샵을 자주 진행해야 한다
• 워크샵에는 도메인 전문가, 제품 책임자, 개발자 등 다양한 이해 관계자 참석이 필수다
• 우리가 만들거나 운영하고자 하는 시스템에 대해서 깊이 있게 논의해보며 언어를 맞추어 나간다
• ex) 워크샵 진행 순서
  1. 우리 시스템에 필요한 기능들을 명사 위주로 나열해볼까요?
     • 회원, 주문, 리뷰, 배송, 고객 문의, 환불, 상품전시, 상품추천, 커뮤니티 등..
  2. 우리 시스템의 사용자 스토리를 브레인스토밍 해볼까요?
     • 고객은 회원가입 페이지에서 계정을 생성할 수 있다
     • 고객은 상품의 이름으로 상품을 검색할 수 있다
     • 판매자는 구매 고객엥게 쿠폰을 제공할 수 있다
     • 관리자는 판매자가 등록한 상품을 리뷰할 수 있다
     • 고객은 구매한 상품의 리뷰를 작성할 수 있다
  3. 나온 내용에 대한 토론
     • 관리자의 등록 상품 리뷰와 구매 상품 리뷰는 같은 것인가?
     • 문맥 상 다르므로 앞의 리뷰는 검사로, 뒤의 리뷰는 평가로 이름을 바꾸자!
     • 이런것처럼 문맥의 경게를 만들어낸다
     • 이 때 문맥의 경게를 만들어 내는 것을 바운디드 컨텍스트라고 한다

---

 

도메인 주도 설계의 세부 개념

• 전략적 설계
  • 유비쿼터스 언어의 정의
  • 바운디드 컨텍스트의 식별
  • 컨텍스트 매핑
• 전술적 설계
  • 도메인을 코드로 구현하기 위한 상세 패턴의 적용
  • Aggregate, Entity, Value Object, Application Service, Repository

 

 

 

전략적 설계

• 마이크로서비스 도출을 위해서 비즈니스 상 전략적으로 중요한 것을 찾아 중요도에 따라 이를 나누는 단계
• 전략적 설계의 두 가지 주요 개념
  • 프로젝트를 수행하는 모든 팀원이 공통으로 사용하는 유비쿼터스 언어
  • 도메인의 주요 개념을 정의하고 도메인 간의 경계를 식별하는 바운디드 컨텍스트

 

 

 

전략적 설계의 필요성

• 애자일 프로젝트 관리 시스템을 개발하는 사례
• 설계 초기에는 핵심이 되는 부분을 설계한다
  • 아래 핵심 영역은 팀의 역량을 모아 반드시 잘 구축해야 되는 영역
  • 구축 이후라도 지속적인 개발을 통해 개선되어야 하는 부분

 

 

 

서브 도메인

 

• 전체의 비즈니스 도메인을 이해 가능한 하위 영역으로 분리가 필요하다
• 전체의 큰 도메인을 분리한 것을 서브 도메인이라고 한다
• 도메인은 관리할 수 있고 이해할 수 있는 수준으로 분리한다
• 3가지 유형의 서브 도메인
  • 핵심 서브 도메인
  • 지원 서브 도메인
  • 일반 서브 도메인

 

 

 

핵심 서브 도메인

• 다른 경쟁자와 차별화를 만들 수 있는 비즈니스 영역
• 프로젝트 목록에서 높은 우선순위를 갖는다
• 소프트웨어 개발에 있어서 전략적으로 가장 큰 투자가 필요한 부분이다

 

 

 

지원 서브 도메인

• 비즈니스에 필수적이지만, 핵심은 아닌 도메인이다
• 그러나 지원 서브 도메인 없이는 핵심 도메인을 성공시킬 수 없다
• 핵심 서브 도메인 다음으로 중요한 도메인이다

 

 

 

일반 서브 도메인

• 시스템에 필요하긴 하지만 큰 공수를 들일 필요는 없는 도메인
• 가장 중요도가 낮다
• 아웃소싱으로 개발하거나 기존 제품의 라이센스 구입 후 사용 가능
• ex) 동영상 인코딩, 고객 관리 서비스 등

 

 

 

서브 도메인

• 거대한 전체 비즈니스 도메인을 핵심 서브 도메인, 지원 서브 도메인, 일반 서브 도메인으로 분리한다
• 서브 도메인을 식별하는 과정을 통해 도메인의 우선순위화가 가능하다
• 어느 부분에 집중적인 투자를 할지 이해하게 되고 이해 관계자들이 합의할 수 있다

 

 

 

바운디드 컨텍스트

• 바운디드 컨텍스트는 의미적으로 동일한 맥락의 경계 또는 범위를 표현한다
• 바운디드 컨텍스트는 유비쿼터스 언어로 표현되기도 한다
• 의미적으로 동일한 맥락의 경계라는 것은 그 범주 내에서 소프트웨어 모델의 각 컴포넌트가 특정한 의미를 갖고 그 특정한 일을 한다는 것을 의미하게 된다
• 비즈니스 경계 내에서 기능들이 응집도 높게 모여있는 것이다
• 바운디드 컨텍스트마다 각각 분리된 소프트웨어의 코드가 산출된다
  • 마이크로서비스
  • 패키지

 

 

 

서브도메인과 바운디드 컨텍스트의 관계

• 서브 도메인은 Problem Space
• 바운디드 컨텍스트는 Solution Space
• Problem Space : 해결해야 하는 도메인 -> 서브 도메인들의 집합
• Solution Space : 해결책을 실제 구현 -> 바운디드 컨텍스트들의 집합
• 보통 하나의 서브 도메인은 하나의 바운디드 컨텍스트를 갖는 1:1 매핑을 이룬다
• 서브 도메인에 하나 이상의 바운디드 컨텍스트가 매핑 가능하다

 

 

 

유비쿼터스 언어와 바운디드 컨텍스트

• SW 개발의 가장 큰 문제 중 하나는 언어의 통일이다
  • 여기서 언어란 컴퓨터 언어가 아닌 회원, 결제 등과 같은 서비스 네이밍이다
• 도메인 전문가와 개발자가 동일한 언어를 서로 다르게 해석한다
  • 같은 도메인을 도메인 전문가와 개발자가 서로 다른 언어로 표현하게 되면 이해하기 어려워진다
  • 이는 좋은 SW 개발의 걸림돌이 될 수 있다
• 도메인 주도 설계는 유비쿼터스 언어를 정의하고 그 언어가 SW에 그대로 반영되도록 한다
• 애플리케이션을 직접 개발하지 않는 사람(제품 책임자, 기획자, 도메인 전문가 등)도 도메인 모델 및 코드를 보고 이해할 수 있어야 한다
• 유비쿼터스 언어는 의사소통할 때와 뿐만 아니라 구현할 때의 소스의 class명, method 명에도 사용되어야 하는 언어이다
• 언어는 문맥 안에서 서로 다르게 이해될 수 있다
  • ex) 사용자
    • 계정 문맥에서의 사용자 = 회원
    • 주문 문맥에서의 사용자 = 주문자
    • 배송 문맥에서의 사용자 = 받는 사람
  • ex) 상품
    • 카탈로그 문맥에서의 상품
    • 재고 관리 문맥에서의 상품
    • 주문 문맥에서의 상품
    • 배송 문맥에서의 상품
• 컨텍스트에 따라 비슷해보이는 언어들이 실제로는 다를 수 있다
• 같은 상품이지만 컨텍스트에 따라 필요한 데이터가 다르다
  • 카탈로그 문멕에서의 상품 - 이미지, 이름, 상세 정보, 평점, 옵션
  • 재고 관리 문맥에서의 상품 - 위치, 재고량, 입고 날짜
• 상품을 Product라는 1개의 테이블과 1개의 클래스로 설계한다면?
  • 컨텍스트의 경계가 없어져 Product의 의미가 모호해진다
  • Product의 데이터를 보면 도대체 어디에 쓰이는 모델인지 파악하기가 쉽지 않다
  • User, Member, Account 등이 하나의 domain 패키지에 있는 거도 동일하게 혼란을 야기한다
  • 경계가 없이 하나의 패키지 안에 있을 때 이들의 역할을 파악하기가 어려워진다
• 따라서 각 문맥별로 상품의 이름을 명확하게 재정의할 필요가 있다
  • 카탈로그 컨텍스트에서의 상품은 Product
  • 재고 컨텍스트에서의 상품은 Stock
  • 주문 컨텍스트에서의 상품은 OrderItem
  • 이를 코드에도 적용하면 코드 자체의 유지보수성 자체가 높아질 수 있다
• 도메인 주도 설계에서는 비슷하지만 서로 다른 개념들을 각기 다른 바운디드 컨텍스트 내부로 분리한다
  • 개념 간 차이를 명확하게 한다
  • 분리된 개념 자체가 서비스로 만들어질 수 있게 된다
• 명확하게 재정의된 개념들은 각가의 바운디드 컨텍스트 내부의 유비쿼터스 언어가 된다