마이크로서비스로 도메인 주도 설계 구현

마이크로서비스에 DDD를 적용하는 것에 대해 이야기할 때 정확히 무엇을 의미합니까? DDD를 마이크로서비스에 적용할 때 어려운 점은 무엇입니까? 답은 마이크로서비스 속성에 있습니다. 여기서 각 마이크로서비스는 다음과 같습니다.

• 독립적이고 완전한 기능 단위
• 독립 개발 단위
• 독립 배포 단위
• 독립 규모 단위
• 데이터 저장소를 직접 노출하지 않음
• 기능에 액세스할 수 있는 API 제공

마이크로서비스 아키텍처 다이어그램

DDD에서는 다양한 수준의 세분성을 처리해야 합니다.

• 엔터티 및 값 개체
• 집계 루트
• 제한된 컨텍스트
• 애플리케이션

DDD 세분성 수준

마이크로서비스가 한쪽에는 독립적이고 독립적인 문제이고 다른 한쪽에는 DDD의 서로 다른 세분성 수준이 있다는 점에서 의문이 제기됩니다. 마이크로서비스를 구축하는 DDD 세분성 수준은 무엇입니까? 경계 컨텍스트별로 마이크로서비스를 구축해야 합니까? 아니면 엔터티 당 또는 중간 어딘가에있을 수 있습니까? 분명히 애플리케이션당 마이크로서비스가 아닙니다. 그렇지 않으면 SOA 또는 Monolith 아키텍처 스타일로 끝납니다.

이 게시물에서 해결하려는 주요 문제는 마이크로 서비스에 대한 올바른 세분성을 결정하는 것입니다.

올바른 세분성은 무엇입니까?

짧은 대답은 "그것은 ...에 달려 있습니다."입니다. 예, 확실한 답은 없지만 여전히 알아낼 수 있습니다. 각 세부 수준을 자세히 살펴보고 해당 수준에서 마이크로 서비스를 생성할 때의 장단점을 찾아보겠습니다.

애플리케이션

이 수준은 전체 응용 프로그램을 나타냅니다. 전체 애플리케이션 도메인 모델이 단일 서비스나 모놀리스에 잘 맞는 경우 마이크로서비스 아키텍처 스타일로 시스템을 설계할 필요가 없을 수도 있습니다. 애플리케이션이 성장함에 따라 마이크로서비스로 마이그레이션하기로 결정할 수 있지만 너무 성급하게 마이그레이션하면 큰 문제가 될 수 있습니다. 우리 도메인 모델이 미래에 어떻게 발전할지 예측하기 어렵습니다. 따라서 조기에 마이크로서비스로 분할하면 추가 리팩토링에 많은 문제가 발생할 수 있습니다. 마이크로서비스 간에 도메인 개체를 이동하는 것은 단일 서비스 또는 모놀리스 내에서만큼 쉽지 않습니다.

제한된 컨텍스트

마이크로서비스로서의 제한된 컨텍스트

제한된 컨텍스트는 마이크로서비스의 좋은 후보가 될 수 있으며 자연스럽게 다른 제한된 컨텍스트와 격리되며 각각은 자체 모델과 유비쿼터스 언어 방언을 기반으로 합니다. 경계 컨텍스트는 인터페이스, API, 격리 계층 등을 통해 통신하며 명확한 경계를 갖습니다. 그러나 제한된 컨텍스트가 큰 경우 단일 마이크로 서비스의 기반으로 사용하는 것은 비합리적이거나 불가능합니다. 단일 도메인 모델을 소유한 팀이 있으므로 단일 경계 컨텍스트가 있습니다. 어떤 상황에서도 이러한 팀은 전체 모델을 마이크로서비스에 포장할 수 있습니다. 따라서 제한된 컨텍스트는 마이크로 서비스의 경계로 사용될 수 있지만, 모델이 작아서 마이크로 서비스가 실제로 마이크로인 경우에만 가능합니다.

집계 루트

마이크로 서비스로 루트 집계

짧은 대답은 집계 루트가 마이크로 서비스를 구축하는 가장 좋은 옵션일 수 있다는 것입니다. 정의에 따르면 집계 루트는 비즈니스 논리와 규칙, 엔터티 및 값 개체의 저장 및 검색과 관련된 모든 복잡성을 캡슐화합니다. 모델의 불변성을 유지 관리하는 역할을 하며 인터페이스를 통해 모델의 기능을 외부 세계에 노출합니다. 이 모든 것은 마이크로서비스가 무엇에 관한 것인지와 매우 유사합니다.

집계 루트에서 마이크로 서비스를 만드는 기술은 일반적으로 간단하고 간단합니다. 집계 루트는 이미 인터페이스를 노출하므로 인터페이스를 가져와 마이크로서비스 API를 통해 노출할 수 있습니다.

집계 루트를 기반으로 마이크로 서비스 생성

엔터티 및 값 개체

마이크로서비스로서의 엔터티

값 개체는 ID가 없는 도메인 개체입니다. 값 개체를 중심으로 마이크로 서비스를 사용하는 것이 합리적인 경우를 이미지화하기 어렵기 때문에 더 이상 논의할 필요가 없습니다.

엔터티는 ID가 있는 도메인 개체입니다. ID가 집계 루트 내에서 유효하더라도 CRUD 작업을 노출하는 엔터티를 중심으로 마이크로서비스를 구축하는 것이 여전히 가능하지만 반드시 그래야 하는 것은 아닙니다. 대부분의 경우 엔터티당 마이크로서비스는 과잉이 되어 전체 시스템의 안정성과 성능에 부정적인 영향을 미칩니다. 어떻게?

음, 마이크로 서비스는 네트워크를 통해 통신하며 네트워크 호출은 진행 중인 호출만큼 안정적이지도 빠르지도 않습니다. 지나치게 세분화된 마이크로서비스는 네트워크 통신량을 증가시켜 전체 시스템을 더 느리고 덜 안정적으로 만드는 경향이 있습니다.

또 다른 단점은 복잡성과 유지 관리 비용이 증가한다는 것입니다. 작은 마이크로서비스가 많으면 시스템 전체를 이해하고 종속성을 탐색하기가 매우 어렵습니다. 전체 시스템이 하나의 단일체처럼 보이거나 심지어 가치가 있는 분산형 단일체처럼 보입니다.

증가된 결합은 또 다른 단점입니다. 엔터티당 마이크로 서비스를 사용하면 응집력 있는 엔터티가 서로 다른 마이크로 서비스로 분할될 가능성이 매우 높습니다. 결합이 증가하면 결합된 마이크로 서비스의 오케스트레이션된 배포가 필요하게 되며, 이는 마이크로 서비스 아키텍처 스타일의 주요 이점 중 하나인 각 마이크로 서비스의 독립적인 배포와 정반대입니다.

엔터티 수준에서 마이크로서비스 결합

요약

그렇다면… 마이크로서비스를 생성할 수 있는 DDD 세분성 수준은 무엇입니까? 실제로 시도할 수 있는 가장 좋은 옵션은 집계 루트 수준입니다. 소수의 경우 바인딩된 컨텍스트도 합리적인 옵션이지만 Entity는 거의 좋은 선택이 아닙니다. 결정을 내릴 때 Aggregate Root로 엄격하게 결정하는 것이 항상 가능한 것은 아닙니다. 때로는 둘 이상의 집계 루트가 마이크로 서비스가 될 수 있으며 마이크로 서비스의 속성을 유지하는 한 괜찮습니다.

Bounded Context와 Aggregate Root 사이 어딘가에 마이크로 서비스 경계를 그리는 것을 생각해 보십시오.

Bounded Context와 Aggregate Root 사이 어딘가

디자인을 선택할 때 목표를 의식적으로 인식해야 합니다. 모든 설계 결정은 복잡성을 최소화하기 위한 절충안입니다. 왜요? 복잡한 시스템은 유지 관리 비용이 많이 들고 새로운 기능을 도입하는 데 상당한 시간이 걸리며 변경하는 데 위험이 따릅니다. 이것은 마이크로 서비스 경계를 그릴 위치를 포함하여 모든 아키텍처 및 디자인 결정의 기본 아이디어입니다.

출처 : https://programhappy.net/2020/10/18/implementing-domain-driven-design-with-microservices/