티스토리 뷰
개요
# 참고
마이크로서비스 도입 이렇게 한다. (Monolith to Microservices)
# 개요
MSA에 대해 이해하고, 모놀로식 아키텍처에서 마이크로서비스 아키텍처로 마이그레이션을 하며 고려해야할 지점에 대해 고민한다.
1장. 더도 덜도 아닌 딱 마이크로서비스
마이크로서비스로 작업하는 방법을 다루기 전에 마이크로서비스 아키텍처가 무엇인지에 대해 보편적인 이해를 공유하는 것이 중요하다.
1-1. 마이크로서비스란 무엇인가?
마이크로서비스란 비즈니스 도메인을 중심으로 모델링된 독립적으로 배포 가능한 서비스다. 마이크로서비스는 네트워크를 통해 서로 통신하며, 마이크로서비스 아키텍처는 여러분이 직면할 수 있는 문제를 해결하기 위한 여러 선택지를 제공한다. 따라서 마이크로서비스 아키텍처는 여러 협업 마이크로서비스를 기반으로 한다.
서비스 경계가 어떻게 형성되어야 하는지에 대해서는 의견이 분분하며, 독립적인 배포가 핵심이긴 하지만, 마이크로서비스도 SOA의 한 유형이다. 마이크로서비스는 또한 기술에 중립적이라는 장점도 있다.
기술 관점에서 마이크로서비스는 하나 이사으이 네트워크 종단점을 통해 캡슐화되는 비즈니스 기능을 외부에 공개한다. 마이크로서비스는 이런 네트워크를 통해 서로 통신하게 되며, 분산 시스템이라는 형태를 구성한다. 또한 잘 정의된 인터페이스를 통해, 데이터 저장소와 인출 기능을 캡슐화하고 데이터를 외부에 공개한다. 따라서 데이터베이스는 서비스 경계 내부에 숨겨져 있다.
# 독립적인 배포 가능성
독립적인 배포 가능성이란 다른 서비스를 활용하지 않고서 마이크로서비에 변경을 가하는 방식으로 서비스 환경에 배포할 수 있따는 개념이다. 독립적인 배포를 위해서는, 서비스가 느슨하게 결합되어 있음을 보증할 필요가 있다. 즉, 다른 서비스를 변경하지 않고도 특정 서비스를 변경할 수 있는 능력을 갖출 필요가 있다. 몇몇 구현 선택은 이를 억렵게 만들며, 일례로 데이터베이스 공유가 특히 문제다. 인터페이스가 안정적인 느슨하게 결합된 서비스가 필요하다면, 먼저 서비스 경계를 찾도록 우리의 생각부터 바꿔야 한다.
요약: MSA는 데이터베이스 분리가 중요하면, DDD 개념을 통해 바운디드 컨텍스트로 서비스를 분리하는 것이 중요하다
# 비즈니스 도메인을 중심으로 하는 모델링
프로세스 경계를 넘어서는 변경에는 비용이 많이 든다. 변경사항의 배포를 조정할 필요가 있는 경우, 단일 서비스 내에서 동일한 변경을 수행하는 것보다 더 많은 직업이 필요하다. 따라서 교차 서비스 변경을 최소로 줄이게끔 보증하는 방법을 찾고자 한다.
전형적인 모놀로식은 인터페이스, 비즈니스로직 계층, 데이터베이스 등 간단한 3계층 아키텍처를 흔히 볼 수 있다. 전형적인 모놀로식 3계층 아키텍처는 우리가 전통적으로 어떻게 팀원들을 그룹으로 묶는지 보여주며, 친밀도를 중심으로 한 조직의 집합에 최적화되어 있을 뿐이다. 그러나 상황이 바뀌었다. 사람들을 다재다능한 팀으로 묶어서 업무 이관과 사일로 현상을 줄였다. 이렇게 함으로써 훨씬 더 빠르게 소프트웨어 출시를 가능하게 한다. 이러한 팀은 비즈니스 기능의 변경에 초점을 맞춘다.
3계층 아키텍처는 기술 관점에서 응집력이 높지만, 비즈니스 기능 관점에서는 응집력이 낮다. 쉽게 변경할 수 있게 만들려면 코드를 그룹화하는 방식을 바꿔야 한다. 즉 기술보다는 비즈니스 기능의 응집력을 선택할 필요가 있다.
요약: 3계층 아키텍처는 보통 팀을 UI/백엔드/DBA 형식으로 계층을 나눈다. 이렇게 나누면 어떤 문제가 있을까? UI에서 변경이 일어나면 백엔드. DBA 코드 모두에 변경이 일어나야 한다. 하지만 팀이 계층별로 나뉘어져 있다 보니 변화에 따르게 대처하지 못한다는 문제가 생기며 팀의 역할에 집중하는 것이 아닌 다른 팀의 역할과 기능을 이해해야지만 작업이 가능하다.
# 데이터 소유권 문제
마이크로서비스는 데이터베이스를 공유해서는 안된다는 생각 때문에 매우 곤란해 하는 사람들을 종종 보곤한다. 어떤 서비스에서 다른 서비스가 보유한 데이터에 접근하고 싶다면 데이터를 보유한 서비스를 찾아서 해당 데이터를 요청해야 마땅하다. 해당 서비스는 외부에 무엇을 공유하고 무엇을 숨길지 결정할 수 있다. 독립적인 배포 가능성을 원한다면 서비스간에 안정적인 인터페이스가 필수다. 외부에 공객하는 인터페이스가 계속 변경된다면, 이를 사용하는 다른 서비스도 변경해야 하는 연쇄 효과가 일어난다.
요약 : 독립적인 배포 가능성을 원한다면, 데이터베이스의 분리는 필수적이다. 하지만 무작정 분리는 좋지 않다. DDD 바운디드 컨텍스트와 Aggregate 개념을 통해서 비즈니스 기능의 응집력을 높일 수 있도록 데이터베이스를 분리해야 한다.
# 마이크로서비스의 장점
마이크로서비스의 장점은 다양하고 많다. 배포의 독립적인 특성으로 인해 시스템의 확장성과 견고성을 개선할 수 있으며, 서비스의 병렬 개발 작업이 가능하므로, 개발자들은 서로 방해받지 않고 각자 문제 해결에 몰입할 수 ㅇ씨다. 또한 개발자가 자신이 맡은 부분에만 전념할 수 있으며, 프로세스 격리를 통해 다양한 기술 선택이 가능하므로, 프로그래밍 언어, 플랫폼, 데이터베이스 등을 다양하게 조합할 수 있다. 또한 가장 중요한 것은 MSA는 유연성을 제공한다.
# 마이크로서비스가 야기하는 문제점
컴퓨터가 저렴해 지면서, 서비스 지향 아키텍처는 인지도를 높이기 시작했다. 거대한 메인 프레임 하나에 시스템을 배포하는 대신, 여러 대의 저렴한 컴퓨터를 사용하는 방식이 가능해졌다. SOA는 여러 컴퓨터에 나뉘어 동작하는 애플리케이션을 가장 잘 구축하는 방법을 찾으려는 시도였다. 이 과정에서 부딪히는 장애물 중 하나는 여러 컴퓨터가 서로 통신하는 방식인 네트워크다
네트워크를 거치는 컴퓨터 간의 통신을 즉각적이지 않다. 이는 특히 로컬 프로세스 내 작업에서 볼 수 있는 대기 시간과 비교해 훨씬 더 긴 대기 시간을 걱정해야 한다는 의미다. 이런 대기 시간이 제각각이라서 시스템 동작을 예측하기 어렵게 만들 때 상황은 더욱 악화된다. 이런 장애물로 인해, 트랜잭션 같은 단일 프로세스 모놀리스로 해결 가능한 비교적 단순한 활동은 훨씬 더 어려워진다. 즉, 트랜잭션과 안전성을 포기해야 한다.
요약 : MSA는 여러 서비스로 나누어 독립적으로 배포하게 된다. 하지만 11번가에서 주문을 할때 데이터는 회원, 상품, 주문 서비스의 데이터가 모두 필요하다. 그렇다면 마이크로서비스 간에 통신을 하여 데이터를 가져와야 하는데, 통신은 즉각적이지 않으므로 데이터베이스의 트랜잭션을 보장하는 것이 쉽지 않다. 이러한 문제를 해결하기 위해 HTTP 통신이나 메시지 브로커가 사용이 되긴 하지만, MSA가 장점만 있으며 절대적으로 좋은 서비스를 의미하지는 않으며, MSA를 이해하지 않으면 많은 위험을 동반할 수 있다고 말할 수 있다.
# 기술
마이크로서비스 아키텍처와 함께 신기술을 적용하려고 하지만, 절대 그 유혹에 빠져서는 안 된다. 새로운 기술을 채택하는 데는 비용도 들고 다소 격변젹이게 된다. 마이크로 서비스를 도입할 때는 충분히 마이크로서비스를 겪어봐야 한다. 분산 시스템과 마이크로서비스 아키텍처는 한 번도 직면하지 못한 문제이다. 따라서 먼저 익숙한 기술 스택을 활용해 문제를 해결하고 나서, 새로운 기술로 변경을 고려하는 방식이 유용하다.
# 규모
마이크로서비스의 목표는 가능한 작은 인터페이스를 유지하는 것이다. 먼저 마이크로서비스 전환에 있어서 규모는 생각하지 말자. 고민해야 하는 것은 딱 두 가지 이다.
1. 어떻게 많은 마이크로서비스를 다룰것인가? 서비스가 많아질 수록 시스템의 복잡성을 증가할 것이고 이에 대처하기 위해 새로운 기술을 배워야 한다. 그렇기 때문에 점진적인 마이그레이션이 중요하다.
2. 모든 것이 끔찍하게 결합된 혼돈 상황이 되지 않으면서 마이크로서비스를 활용하기 위해서는 경계를 정의하는 방법이 중요하다. 이 경계는 어떻게 정의할까? (DDD)
1-2. 모놀리스
이 책은 모놀리스에서 마이크로서비스로 이전하는 내용을 집중적으로 다루므로 모놀리스라는 용어의 의미가 중요하다. 모놀리스는 주로 배포 단위를 말하는 것이다. 시스템의 모든 기능을 함꼐 배포해야 할 때, 이를 모놀리스로 간주한다. 모놀리스 시스템은 3가지의 유형이 있다.
1. 단일 프로세스 시스템
2. 분산 모놀리스 시스템
3. 외부 블랙박스 시스템
# 단일 프로세스 모놀리스
모놀리스를 논의할 때 가장 일반적인 예이다. 모든 코드가 단일 프로세스로 배포되는 시스템으로 견고성 또는 확장성을 이유로 모든 코드는 단일 프로세스로 묶어 배포된다. 이런 시스템은 데이터를 거의 항상 데이터베이스에서 읽거나 데이터베이스에 저장하기 때문에, 단순하면서도 독자적인 분산 시스템일 수 있다.
# 모듈식 모놀리스
모듈식 모놀리스는 단일 프로세스 모놀리스의 일종의 변형이다. 모듈식 모놀리스는 각 모듈들이 독립적으로 동작할 수 있지만, 배포를 위해서는 여전히 결합이 필요하다. 많은 조직에서 모듈식 모놀리스는 탁월한 선택이 될 수 있다. 모듈 경계가 잘 정의되어 있으므로 병렬 작업을 많이 수행할 수 있지만 배포 고려사항은 훨씬 더 단순해지기 때문에, 부산 마이크로서비스 아키텍처에서 발생하는 문제를 피할 수 있따. 모듈식 모놀리스는 MSA 대안으로 휼륭한 예이다. 하지만 데이터베이스 부분에서는 분해 능력이 부족하기 때문에 여전히 문제가 남아 있다.
요약 : 음.. 멀티 모듈 프로젝트랑 비슷한 개념일까? 우리는 멀티 모듈을 계층으로 나누었지만 비즈니스 도메인으로 나누면 책에서 설명하는 방식이 될 것 같다.
# 분산 모놀리스
분산 모놀리스는 여러 서비스로 구성된 시스템이지만 어떤 이유로든 전체 시스템을 함께 배포해야만 한다. 분산 모놀리스는 분산 시스템의 모든 단점에다가 단일 프로세스 모놀리스의 단점까지 포함하며, 양쪽의 장점을 충분히 발휘하지 못한다. 분산 모놀리스는 전형적으로 정보은닉이나 비즈니스 기능의 응집력 같은 개념이 희박한 환경에서 등장한다. 또한 서비스 경계 지점에서 변경이 발생하기에 결합도가 매우 높은 아키텍처를 만들어내며, 지역적인 범위에서 나쁜 의도가 없는 듯한 변경사항이 외부까지 영향을 미쳐 시스템의 다른 부분을 망가뜨린다.
# 외부 블랙박스 시스템
몇몇 외부 소프트웨어를 모놀리스로 간주할 수도 있다. 이 소프트웨어의 공통점은 다른 사람들이 개발했기에 우리에게는 코드를 변경할 역량이 없다.
# 모놀리스의 문제점
단일 프로세스 모놀리스나 분산 모놀리스 등은 종종 결합도, 특히 구현과 배포 결합도와 같은 결합도의 위험에 더 취약하다. 같은 장소에서 일하는 사람들이 점점 많아질수록, 저마다 각자의 길을 가게 된다. 동일한 코드를 변경하기 원하는 다양한 개발자, 각 기능을 각기 다른 시점에 밀어넣고 싶어하는 팀들이 많다. 누가 의사결정을 하고, 누구의 책임에 대한 혼란도 존재한다. 이런 혼란스러운 소유권의 경계를 '배포 경합'이라고 부른다.
모놀리스를 사용한다고 해서 반드시 배포 경합 문제에 직면하는 것은 아니며, 마이크로서비스 아키텍처를 사용해서 배포 경합 문제를 피할 수 있는 것도 아니다. 그러나 MSA는 소유권의 경계선을 중심으로 더 구체적인 경계를 제공하므로 문제를 해결하기 위한 유연성이 훨씬 더 뛰어나다.
# 모놀리스 장점
단일 프로세스 모놀리스에는 장점도 많다. 간단한 배포 토폴로지로 분산 시스템과 관련된 많은 위험을 피할 수도 있다. 모놀리스는 훨씬 더 간단한 개발자 워크 플로우를 만들어낸다. 또한 모니터링, 문제해결, 전 구간 테스트와 같은 활동도 크게 단순화할 수 있다.
또한 모놀리스 자체 내에서 코드 재사용을 단순하게 만든다. 분산 시스템 내에서 코드 재상용을 원하면, 코드를 복사할지, 라이브러리를 분해할지, 공유기능을 서비스로 분리할지를 고민해야 하지만, 모놀리스는 그냥 필요한 코드를 사용하기만 하면 된다.
또한 많은 사람들이 모놀리스는 레거시하고 피해야할 아키텍처로 생각한다. 하지만 MSA가 모든 상황에서 정답은 아니다. 따라서 두 방식의 장,단점을 이해하고 합리적인 결정을 해야 한다.
1-3. 결합도와 응집력
마이크로서비스의 경계를 정의할 때 결합도와 응집력 사이의 균형을 이해해야 한다. 구조는 응집력이 높고 결합도가 낮을때 안정적이다.
결합도 : 한 가지를 바꾸면 다른것도 바꿀 필요가 있는 방식
응집력 : 관련된 코드를 그룹으로 묶는 방식
모놀리스의 문제점은 결합도와 응집력이 너무나 자주 반대로 움직이는 것이다. 응집력이 있는 코드를 함께 변경이 가능하게 유지하는 대신, 관련 없는 모든 유형의 코드를 가져와서 한데 붙여 놓는다. 느슨한 결합은 실제로 존재하지 않는다. 코드의 한 줄은 쉽게 변경할 수 있을지도 모르지만, 모놀리스의 나머지 부분에 잠재적인 영향을 미치지 않으면서 해당 변경사항을 배포할 수는 없으며, 전체 시스템을 확실히 재배포 해야 한다.
요약 : 모놀로식 시스템에서 DTO 클래스의 변수 명에 실수로 철자를 틀렸다. 이를 수정하기 위해서는 코드를 수정하고 전체 시스템을 재 배포 해야 한다.
# 응집력
응집력은 "함께 바뀌고 함께 머무는 코드"로 정의할 수 있다. 가능한 적은 장소에서 변경할 수 있는 방식으로 기능을 그룹으로 묶어야 한다.
# 결합도
응집력을 선호하지만 결합도는 경계해야 한다. 결합도가 높은 항목이 많을수록 변경해야 하는 내용도 더 많아진다.
1. 구현 결합도
구현 결합도는 가장 위험한 형태의 결합도지만, 가장 쉽게 결합도를 낮출수 있다. 구현 결합도의 고전적이고 일반적인 예는 데이터베이스를 공유하는 형태로 나타난다.
추천에는 고객이 넣은 주문 정보가 필요하다. 그러나 이런 상황에서는 구체적인 스키마 구조, SQL언어 심지어 행의 내용까지 우리의 구현 내용과 결합된다. 주문 서비스가 열 이름을 변경하거나 고객 주문 테이블을 분리한다면, 개념적으로 여전히 주문 정보를 폼함하지만 추천 서비스가 이 정보를 가져오는 구현 방식을 망가뜨린다. 이런 구현 세부사항을 감처는 것이 더 바람직한 방법이며, 추천 서비스는 API호출을 통해 필요한 정보에 접근한다.
요약: 여러 개의 마이크로서비스가 분리되어 있는데 하나의 데이터베이스를 공유하는 상황에서 데이터베이스의 내용이나 기술적인 부분이 변경되면 어떻게 될까? 참조하는 서비스도 코드 변경이 필요하다. 때문에 직접 참고하는 것이 아닌 API 통신을 통해 내부 구현을 숨기라는 것이다. 이렇게 하면 제공해 주는 정보만 받아 사용하면 된다.
주문 서비스가 데이터베이스 형태로 데이터 집합을 게시하도록 만들 수 있으며, 이는 그림3 처럼 컨슈머가 대량으로 접근하기 위해 사용됨을 의미한다. 주문 서비스가 적절히 데이터를 게시할 수 있는 한, 공개 계약을 유지하므로 주문 서비스 내에서 변경된 사항은 컨슈머에게 보이지 않는다. 또한 컨슈머에게 공개된 데이터 모델을 개선해 필요에 따라 조율할 수 있는 기회를 열어 놓는다.
실제로 그림2, 그림3은 정보 은닉을 잘 사용하고 있다. 잘 정의된 서비스 인터페이스 뒤에 데이터베이스를 숨기면 서비스가 노출 대상의 범위를 제한하고 데이터 표현 방식을 변경할 수 있다.
2. 시간 결합도
시간적 결합도는 주로 분산환경에서 동기식 호출의 주요 도전과제 중 하나인 실행시간에 발생하는 문제다. 메시지가 전송되는 시점과 메시지가 처리되는 방식이 시간과 관련되어 있는 경우, 시간적 결합도가 존재한다고 말한다.
창고, 주문, 고객 서비스는 HTTP 호출을 통해 정보를 가져 오고 있다. 3가지 서비스 모두 시간적으로 결합되어 있따고 볼 수 있다. 이 문제는 다양한 방법으로 해소 가능하다. 먼저 캐싱 사용을 고려하자. 주문 서비스가 고객 서비스에서 필요한 정보를 캐시하면 주문 서비스는 몇몇 경우에 다운스트림 서비스와 시간적 결합도를 피할 수 있을 것이다. 또한 메시지 브로커 같은 서비스를 사용하면 비동기 전송을 고려할 수도 있다. 메시지 브로커가 메시지를 다운스트림 서비스로 보내 놓으면 다운스트림 서비스가 여유가 생긴 시점에 해당 메시지를 처리한다.
3. 배포 결합도
단일 프로세스를 생각해 보자. 코드 한 줄이 변경이 되었으며 해당 변경사항을 배포하기를 원한다면 전체 모놀리스를 배포해야 한다. 이를 배포 결합도라고 한다. 배포와 관련된 위험을 줄이는 방법은 여러가지가 있는데, 그중 하나는 변경할 필요가 있는 사항만 바꾸는 것이다. 더 큰 프로세스를 독립적으로 배포 가능한 마이크로서비스로 분해해 배포 결합도를줄일 수 있따면, 배포 범위를 줄임으로써 개별 배포의 위험을 낮출 수도 있다.
릴리스 규모가 작을수록 위험 부담도 줄어든다. 변경을 줄였기 때문에 뭔가가 잘못되어도 문제를 찾아내 해결하기가 쉬워진다. 릴리스 규모를 줄이는 방법을 찾는 것으 지속적인 배포의 핵심이며, 빠른 피드백과 맞춤식 릴리스 방버의 중요성을 뒷받침한다. 릴리스 범위가 작을수록 출시도 쉽고, 안전하며, 빠른 피드백을 얻을 수 있다.
4. 도메인 결합도
독립적인 서비스로 구성된 시스템은 참가자 간에 상호작용이 있어야만 동작한다. 마이크로서비스 아키텍처에서 도메인 결합도는 결과며, 서비스 간의 상호작용은 실제 도메인에서 일어나는 상호작용을 모델링한다.
주문하려면 고객의 쇼핑 바구니에 어떤 물품이 있는지 알아야 한다. 제품 배송을 원하면 제품을 어디로 배송할지 알아야 한다. 우리는 전체 주문을 창고와 공유하고 있는데, 이는 합리적이지 않을지도 모른다. 창고는 포장할 대상 물품과 배송지에 대한 정보만 필요하기 때문이다. 물품 가격이 얼마인지 알 필요가 없다. 접근제어가 필요한 정보에 문제가 생길 수도 있다. 전혀 무관한 서비스에 신용카드 세부정보를 노출할 수도 있다. 창고 서비스가 고객에 대해알아야 할 필요성조차 없애는 방식으로, 결합도를 더욱 줄일 수 있다.
이러한 도메인 서비스 간에 호출은 API호출 혹은 이벤트를 소비하도록(메시지 브로커) 하는 방식이 있다. 이벤트를 발생시키는 방식으로, 종속성을 효과적으로 뒤집을 수 있다. 주문 처리 서비스로부터 이벤트를 수신하는 창고 서비스로 초점을 이동한다.
2가지 접근법 모두 고유한 장점이 있으며, 우리의 선택은 주문 처리 로직과 창고 서비스에서 캡슐화된 기능 간의 상호작용에 대한 이해에 달려 있을 것이다. 기본적으로, 창고 서비스가 작업을 수행하려면 주문에 대한 몇 가지 정보가 필요하다. 이런 수준의 도메인 결합도를 피할 수는 없다. 우리가 공유하려는 개념이 무엇인지, 또 그 개념을 어떻게 공유해야 하는지를 신중하게 생각한다면 결합도 수준을 줄이려는 목표를 달성할 수 있다.
1-4. 더도 덜도 아닌 딱 도메인 주도 설계
비즈니스 도메인을 중심으로 서비스를 모델링하면 마이크로서비스 아키텍처에 엄청난 장점이 생긴다. 모델링을 위해서는 도메인 주도 설계(DDD)가 사용이 되며 중요한 개념을 제시한다.
# 집계
도메인 주도 설계에서 Aggregate는 다소 혼란스러운 개념이며, 다양한 정의가 존재한다. 집계는 단순히 임의의 객체 모음일까? 데이터베이스에서 꺼내야 하는 가장 작은 단위는 무엇일까? Aggregate은 일반적으로 수명주기가 있으므로 상태 머신으로 구현할 수 있다. 우리는 Aggregate를 독립된 단위로 취급하기를 원한다.
Aggregate와 MSA를 생각해보면, 단일 마이크로서비스는 하나 이상의 다양한 집계의 수명주기와 데이터 저장소를 처리할 것이다. 다른 서비스의 기능이 집계 중 하나를 변경하려는 경우, 해당 집계의 변경을 직접 요청하거나, 집계 자체를 시스템의 다른 구성 요소에 반응 시켜서 시스템 자체의 상태 전환을 개시해야 한다. 즉, 결론적으로 고객과 주문은 별도의 집계로 모델링하는 것이 좋으며, 각각 다른 서비스에서 처리하는 것이 좋다.
# 경계 컨텍스트
경계 컨텍스트는 일반적으로 조직 내부의 더 큰 조직적인 경계를 나타낸다. 해당 경계 내에서 명시적인 책임이 수행돼야 한다. 경계 컨텍스트는 구현 세부사항을 숨긴다. 여기에는 내부적인 고려사항이 있다. 예를 들어, 어떤 종류의 지게차가 쓰이는지는 창고 직원 이외의 다른 사람에게는 관심을 끌지 못한다. 이런 내부적인 고려사항은 외부 세계로부터 숨겨져 있어야 마땅하다. 다른 사람들이 알 필요도 없으며 신경을 써서도 안 된다.
구현 관점에 경계 컨텍스트는 집계를 하나 이상 포함한다. 일부 집계들은 경계 컨텍스트 외부로 공개될 수도 있으며, 또 다른 집계들은 내부적으로 숨겨져 있을지도 모른다.
# 집계와 경계 컨텍스트를 마이크로서비스에 매핑
집계와 경계 컨텍스트는 외부의 더 넓은 시스템과 상호작용하기 위해 잘 정의된 인터페이스로서 응집력을 제공한다. 집계는 우리 시스템에서 단일 도메인 개념에 중점을 둔 독자적인 상태 시스템으로, 관련된 집계의 집합을 표현하는 경계 컨텍스트와 함께 여기서도 더 넓은 세계의 명시적인 인터페이스를 제공한다. 따라서 집계와 경계 컨텍스트 모두 서비스 경계로 작동할 수 있다. 즉, 집계 경계를 중심으로 분할하는 방법을 모색하자.
# 정리
마이크로서비스는 비즈니스 도메인을 중심으로 모델링한 독자적으로 배포가 가능한 서비스이다. 마이크로서비스는 네트워크를 통해 서로 통신을 한다. 도메인 주도 설계와 함께 정보 은닉 원칙을 사용해 독립적으로 작업하기 쉽도록 경계가 안정적인 서비스를 만들며, 다양한 형태의 결합도를 줄이기 위해 최성을 다해야 한다
.