1.3 분산 아키텍처와 도메인 주도 설계: 모델과 구현을 연결하기 위한 세 가지 설계 패턴 #1530
Description
1.3 분산 아키텍처와 도메인 주도 설계: 모델과 구현을 연결하기 위한 세 가지 설계 패턴
1.3.1 전략적인 설계
단일 모델과 분산 모델
기존의 소프트웨어 설계에서는 비즈니스 활동 전체를 하나의 모델로 생각하는 것이 일반적이었습니다.
트리 구조나 피라미드 구조로 전체를 하나의 모놀리스(monolith) 구조로 보고, 이를 세분화하여 전체를 구성하는 요소들을 정의하는 방식입니다.
하지만 이러한 접근 방식은 전체 구조가 고정되어 유연성과 발전성을 잃게 됩니다.
이에 반해 분산 모델에서는 전체를 독립적으로 활동하는 각각의 구성 요소들이 동적으로 연결되어 네트워크를 구성하는 것으로 봅니다.
구성 요소(컴포넌트)를 독자적으로 수정할 수 있고, 구성 요소 간 연결 방식도 시간이 지남에 따라 변화할 수 있다는 것입니다.
이 가변성이 시스템 전체의 유연성과 발전성을 만들어냅니다.
도메인 주도 설계의 ‘전략적 설계’는 전체를 거대한 단일 모델로 보는 것이 아니라 독립성이 높은 구성 요소들이 역동적으로 연결된 네트워크를 기본 개념으로 삼습니다.
그리고 이러한 분산 모델에 관한 개념이 마이크로서비스 등 분산 아키텍처의 설계 원칙으로 주목받고 있습니다.
도메인 주도 설계 및 분산 아키텍처
도메인 주도 설계는 분산 아키텍처 모델을 제공합니다.
어떤 단위로 분할할지, 어떻게 연결할지를 검토하고 판단하기 위한 모델입니다.
분산 아키텍처는 그 분산 모델을 어떻게 구현할 것인가에 대한 수단을 제공합니다.
특히 분산된 컴포넌트들이 어떻게 연결되고 통신할 것인가는 중요한 관심사입니다.
도메인 주도 설계가 제공하는 분산 아키텍처 모델의 핵심은 다음 세 가지 패턴입니다.
- 경계 컨텍스트
- 컨텍스트 맵
- 핵심 도메인
1.3.2 분산 아키텍처란?
단일 모델과 분산 모델의 관계에서 소프트웨어 아키텍처를 생각하면 다음과 같이 분류할 수 있습니다.
- 단일 모델 지향(모놀리스 아키텍처)
- 중간적인 모델(모듈러 모놀리스)
- 분산 모델 지향(마이크로서비스 아키텍처)
모놀리스 아키텍처
업무 활동 전체를 하나의 모델로 간주하고, 단일 모델로 구현하는 방식이 모놀리스 아키텍처입니다.
모든 기능이 단일 애플리케이션으로 운영되며, 모든 데이터를 단일 데이터베이스로 관리합니다.
모듈러 모놀리스
애플리케이션의 변경이 전체에 영향을 미치지 않도록 하기 위한 방안으로 애플리케이션을 기능별로 분할하여 변경이 필요한 부분만 개발, 테스트, 재배치할 수 있도록 하는 방법입니다.
모듈러 모놀리스에서는 서비스를 독립적으로 개발하고 재배치할 수 있으므로 모놀리스 아키텍처에 비해 변경이 용이합니다.
하지만 모듈러 모놀리스에서는 단일 데이터베이스를 통해 서비스 간 연동이 이루어지기 때문에 데이터베이스와 관련된 변경은 모놀리스 아키텍처와 동일한 문제가 발생합니다.
마이크로서비스 아키텍처
기능의 분할뿐만 아니라 데이터베이스도 분할하는 것이 마이크로서비스 아키텍처입니다.
마이크로서비스 아키텍처에는 두 가지 큰 과제가 있습니다.
- 서비스 간 연결 방법
- 서비스 간에 공유해야 할 데이터 처리 방법
서비스 간 연결을 어떻게 할까
마이크로서비스 아키텍처에서는 통신으로 서로 연결합니다.
연결 수단을 데이터베이스 공유에서 통신으로 바꾸면 개별 서비스 간의 독립성을 높일 수 있습니다.
통신은 데이터베이스에 비해 느리고 불안정합니다.
실시간으로 연결 상태를 확인하고 재시도하는 등 데이터베이스를 이용할 때는 거의 신경 쓰지 않았던 문제들에 대한 추가적인 대응이 필요합니다.
서비스 간 데이터를 어떻게 공유할까?
이를 실현하는 방법에는 몇 가지 선택 사항이 있습니다.
- 매번 필요한 정보를 다시 조회한다.
- 정보 공유를 위한 서비스를 만든다(예 상품 카탈로그 서비스).
- 정보를 복제한다(이용하는 쪽에서 캐시한다).
독립성과 발전성을 실현한다는 분산 아키텍처의 목적에 비추어 볼 때 서비스 간 실시간 의존성을 줄여 주는 세 번째 ‘정보를 복제하는 방법’이 좋은 선택입니다.
서비스 간 연결과 데이터 공유는 여러 가지 방법으로 구현할 수 있습니다.
어떤 방법을 선택하더라도 트레이드오프(trade-off) 관계가 발생합니다.
분산 아키텍처의 구현 방법과 트레이드오프를 알기 쉽게 정리한 책인 <소프트웨어 아키텍처 The Hard Parts>(한빛미디어, 2022년)는 분산 아키텍처를 구현할 때 많은 도움이 될 것입니다.
1.3.3 도메인 주도 설계 도입하기
최근 분산 아키텍처에 대한 논의에서 도메인 주도 설계의 개념을 참고하는 경우가 많은 이유는 무엇일까요?
그것은 <도메인 주도 설계>에서 경계 컨텍스트의 개념이 분산 아키텍처의 개념과 닮은 점이 많기 때문입니다.
경계 컨텍스트
경계 컨텍스트란 도메인 모델을 만들 때 용어의 의미가 같은 범위와 다른 범위를 구분한다는 개념입니다.
다시 말해, 도메인 모델을 만드는 대상 범위를 한정함으로써 의도가 명확하고 모순되지 않는 도메인 모델을 만들 수 있다는 뜻입니다.
경계 컨텍스트에 따라 업무의 목적과 관심사가 다른 영역을 구분하여 영역별로 명확하고 일관성 있는 도메인 모델을 만들 수 있도록 합니다.
컨텍스트 구분 방법
팀
팀 구성이 다르면 같은 용어를 같은 의미로 사용하지 않을 수도 있습니다.
요구사항의 출처
요구사항의 출처(고객이나 제품 소유자)가 다르면 하나의 모델에서 일관된 의미를 유지하기가 어렵습니다.
소스코드 관리
하나의 도메인 모델을 여러 소스 코드 단위로 나누어 버리면 도메인 모델의 일관성이 사라집니다.
또한 하나의 소스 코드에 여러 도메인 모델이 뒤섞이면 각각의 도메인 모델의 독립성이 손실됩니다.
데이터 소유권
데이터 소유권 또는 데이터베이스 테이블 설계에 대한 변경 관리 범위는 도메인 모델이 통용되는 범위에 큰 영향을 미칩니다.
경계 컨텍스트와 서비스 규모
하나의 도메인 모델을 기반으로 하는 애플리케이션에서 특정 기능만이 고도의 확장성이나 가용성을 요구하는 경우를 가정해 봅시다.
이런 경우에는 비기능적 요건만을 다른 서비스로 나누어서, 확장성이나 가용성을 확보할 수 있습니다.
몇 개의 컨텍스트와 서비스로 나누려고 해도 아직 경계가 명확하지 않은 경우가 있을 수 있습니다.
이럴 때는 일단 하나의 도메인 모델로 개발하다가 경계가 명확해진 부분부터 별도의 서비스로 분리하는 것이 좋습니다.
1.3.4 서비스 간 연동 방법과 도메인 주도 설계
서로 다른 도메인 모델을 기반으로 여러 서비스를 연결할 때 연결 방식을 지속적으로 개선하기 위한 방법이 바로 컨텍스트 맵입니다.
컨텍스트 맵
각 도메인 모델의 배경이 되는 경계 컨텍스트를 열거하고, 연결이 필요한 컨텍스트 사이를 선으로 연결하면 그림의 형태로 컨텍스트 맵이 완성됩니다.
실제 서비스 연동은 문제가 복잡합니다.
에반스는 그 원인 중 하나를 팀 간의 의사소통에서 찾았습니다.
기술적인 해결책이 있더라도 실제로 서비스와 서비스를 연결하려면 여러 가지 조정이 필요합니다.
대등한 관계, 편향된 관계, 단절된 관계 이 세 가지를 전제로 하는 컨텍스트 간 연결 방법을 다음과 같은 몇 가지 유형으로 분류했습니다.
| 팀 간 관계 | 컨텍스트 간 연결 방법 | 설명 |
|---|---|---|
| 대등한 관계 | 파트너십 | 서로가 윈-윈 관계에서 협력한다. |
| 대등한 관계 | 공유 커널 | 공통 로직을 공동 소유한다. |
| 편향된 관계 | 고객과 공급자 | 서비스 제공자가 사용자를 만족시킨다. |
| 편향된 관계 | 순응자 | 서비스 제공자의 모델을 사용자가 그대로 사용한다. |
| 편향된 관계 | 부패 방지 계층 | 사용자가 변환한다. |
| 편향된 관계 | 공개 호스트 서비스 | 제공자가 변환한다. |
| 단절된 관계 | 각자 연결 | 특별히 조정하지 않는다. |
서비스 간 조정 방식
다음과 같이 필요한 부분만 발췌하여 상대방에게 정확하게 전달하는 방법이 있습니다.
- API 사양 공개
- 테스트 사양 공개
- 테스트 환경 제공
컨텍스트 맵은 누가 만드나?
컨텍스트의 도메인 모델을 담당하는 팀이 어떤 형태로든 컨텍스트 맵을 만들고 계속 개선해야 합니다.
컨텍스트 맵이라는 큰 모델에서도 설계와 구현이 확실히 연결되는 것이 도메인 주도 설계의 기본 원칙입니다.
1.3.5 핵심 도메인에 집중하기
집중해야 할 핵심 도메인을 식별하기 위해 다음 두 가지 관점을 결합합니다.
- 업무 로직의 복잡성: 업무 프로세스와 업무 규칙의 복잡성
- 업무의 고유성: 자사만의 고유한 업무 방침을 가지는 것이 중요한지, 아니면 타사와 동일한 방식이어도 상관없는지?
이 영역에서는 비즈니스의 경쟁 우위를 획득하고 유지하기 위해 업무 방식과 업무 규칙이 빈번하게 변경됩니다.
비즈니스가 성장하고 발전하기 위한 핵심 업무의 영역이며, 이를 지원하는 소프트웨어를 만든다는 목적을 달성하기 위해 도메인 주도 설계를 활용해야 하는 영역입니다.
기타 영역의 개발 정책
표 1-5 소프트웨어 개발 정책: 세 가지 선택 사항
| 선택 사항 | 모델/설계/구현 | 특성 | 발전성 |
|---|---|---|---|
| 완제품 | 고정(설정 변경은 가능) | 단기 도입, 타사도 이용 가능 | △ |
| 이지 오더, 로우 코드/노코드 | 모델을 만들기 위한 모델(메타 모델)과 실행의 틀을 제공, 부분적인 프로그래밍이 가능 | 메타 모델에 의존, 사용자 정의(커스터마이즈)용 UI를 제공 | × |
| 풀 오더 | 모델도 설계도 독자적으로 수행 | 고위험, 고비용 | |
도메인 주도 설계는 핵심 업무 영역을 대상으로, 비즈니스와 함께 발전하는 소프트웨어를 만들기 위한 설계 기법입니다.
풀 오더 방식으로 임하는 부분이, 바로 도메인 주도 설계를 활용해야 하는 영역입니다.