Devops Day 43 (5.4) 마이크로서비스_도메인 주도 설계와 모놀리식 분해 전략

도메인 지식 : 어떤 산업 또는 분야를 이해하기 위해 필요한 지식
도메인 : 개발 분야에서는, 소프트웨어로 해결하려는 문제의 영역을 의미

도메인을 표현하는 대표적인 사례 : 객체 지향 프로그래밍 (온라인 서점의 예)

도메인 모델 (예시)

- 어떤 도메인을 개념적으로 표현하는 방법 (객체지향 설계, ERD 등)

 

도메인 주도 설계 (Domain Driven Design)
- 하나의 도메인 모델에 대한 이해관계가 각자 다름을 인정하고, 각 팀에 적합한 하위 도메인을 설정하고 해당 하위 도메인에 대한 맥락을 알고 있는 사람이 따라야 할 비즈니스 규칙에 대한 경계를 설정하는 설계 방식

 

배달의 민족의 Order 도메인 (주문이란 무엇인가?)
Order 클래스 분해 전략

도메인 주도 설계의 주요 용어
보편 언어 (ubiquitous language)
- 도메인의 특정 업무와 관련된 사람들 사이에서 통용되는 개념
- 한정된 맥락인 Bounded Context 내에서 협업 구성원들간 보편적으로 통용되는 도메인 언어가 유비쿼터스 언어입니다.

한정된 맥락 (bounded context)
- 모델의 경계를 분명하게 구분짓고, 업무 범위 내로만 아키텍처를 구성한다
 > 한 개의 모델로 모든 하위 도메인을 정확하게 표현할 수는 없으며, 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 합니다
- 독립적인 영역은 도메인 모델링을 위해 사용되며, 비즈니스 요구사항에 따라 서로 다른 모델을 적용할 수 있습니다
- 예시 : 상품 도메인에서의 상품, 배송 도메인에서의 상품, 주문 도메인에서의 상품은 이름만 같지만 실제로 의미하는 것이 다릅니다
참조 : https://www.msaschool.io/operation/design/design-two/

 

시나리오 : 교육 상품의 구매와 교육과정 수강
개발자 :
- 수강과 상품 구매는 사실상 동일한 행위지만 SRP를 지켜야 하니깐 클래스를 분리
- Product 와 Course 클래스를 만들고, Student 의 구매 행위에 따라 자동으로 코스가 열리도록 비즈니스 로직을 짜자
“Devops 1기를 듣는다” -> 이 요구사항을 모놀리틱(단일 프로그램) 아키텍처로 구성한다면?

사업기획부 :
- 소프트웨어 부트캠프 수강 비율이 저조한데 소프트웨어 부트캠프 상품을 구매할 경우 Devops 부트캠프도 같이 수강할 수 있게 해주면 어떨까요?

엔지니어링 팀의 대응:
- 엔지니어링 팀은 두 팀의 요구사항을 맞추기 위해, 두 팀의 맥락을 먼저 이해하고, 비즈니스 로직을 변경했습니다.
- 다 만들고 배포한 후, 두 팀이 다같이 달려들어서 테스트를 진해했습니다.

개발자 :
- 이 정도의 작은 규모의 변경은 어렵지 않았는데…이대로 괜찮을까?

- 업무 범위를 나누세요 : 모델의 경계를 분명하게 구분짓고, 업무 범위 내로만 아키텍처를 구성하면 됩니다 -> Bounded Context

- 이렇게 하면, 보편 타당한 클래스 이름 짓기가 가능해집니다.
- 모든 도메인에 용어를 맞추기 위해 모호한 단어를 쓸 필요가 없습니다. -> Ubiquitous language

- 서비스를 나누세요 : 데이터베이스도 서비스 별로 두세요