다른 마이크로 서비스 간의 공유 도메인 모델


61

서로 다른 두 가지 마이크로 서비스 시나리오를 상상해보십시오. 하나는 서비스 내에서 인증을 처리하고 다른 하나는 사용자 관리를 관리합니다. 둘 다 사용자 개념을 가지고 있으며 서로에게 전화를 통해 사용자에 대해 이야기합니다.

"사용자"의 도메인 모델은 어디에 속합니까? 둘 다 사용자가 데이터베이스 레벨에있는 것과 다른 표현을 가지고 있습니까? API 호출에 사용되는 UserDTO가있는 경우 둘 다 각자의 API에 대해 하나가 있습니까?

이런 종류의 건축 문제에 일반적으로 인정되는 솔루션은 무엇입니까?

답변:


36

Microservices 아키텍처에서 각 아키텍처는 서로 독립적이며 내부 구현의 세부 정보를 숨겨야합니다.

모델을 공유하는 경우 마이크로 서비스를 결합하고 있으며 각 팀이 제한없이 마이크로 서비스를 개발할 수있는 가장 큰 장점 중 하나와 다른 마이크로 서비스의 진화 방식을 알 필요가 없습니다. 각 언어마다 다른 언어를 사용할 수도 있다는 점을 기억하십시오.

그들이 너무 관련이 있다면 아마도 @soru가 말하는 것과 같습니다.

관련 질문 :


21
나는 완전히 동의 할 수 없습니다, 그들이 완전히 독립적이라면 당신은 2 개의 모놀리스가 있습니다. 스마트 엔드 포인트와 멍청한 파이프를 사용하는 것이 좋습니다. 엔터프라이즈 컨텍스트에서는 암시적인 공통 도메인 모델이 있기 때문에 (현재 예측하지 못함) 벽에 부딪 히고 (예상하지 않았기 때문에 암시 적) 각 서비스가 바퀴의 %를 재발 명합니다. 그리고 기능과 팀 소유권에 100 %를 집중하여 도메인 모델을 망쳐 놓고 마이크로 서비스의 생태계가 성장하고 있습니다. 우리는 새로운 서비스를 만들고 다른 사람들을 소비하며 많은 노력을 복제하는 팀이 있습니다. 여전히 해결되지 않았습니다.
juanmf

5
또한 매우 중요한 아키텍처 중요 비 기능적 요구 사항 인 성능을 제외했습니다. 다른 서비스의 출력이 필요한 이러한 서비스는 각 클라이언트 RQ에 대한 다단계 통신 접근 방식을 제공합니다. 리팩터링과 마이크로 서비스 병합이 이루어지지 않으면 해결 될 수없는 지연 시간 추가
juanmf

3
또한 도메인 모델에 대한 일반적인 이해가 없어도 팀은 불필요한 "비 정렬 화 + 객체-개체 변환"을 적용하여 호출 마이크로 서비스가 채택한 모델에 마이크로 서비스 응답을 적용했습니다. 모든 서비스를 공통 도메인 모델 lib에 결합하면 다른 운영상의 문제가 발생할 수 있지만 어느 옵션도 만족스럽지 않다는 것을 알고 있습니다.
juanmf

3
@juanmf 문제에 관한 질문을 게시 할 수 있다면 매우 가치가 있습니다. 또한이 문제에 대한 의견을 듣고
싶습니다

1
나는 앉아서 의미있는 것을 쓰려고 노력할 것입니다
juanmf

13

두 서비스가 충분히 얽혀있어 DTO와 다른 모델 객체를 공유하지 않고 서비스를 구현하기가 어려울 경우, 두 서비스가 없어야한다는 강력한 신호입니다.

확실히이 예는 두 가지 서비스로 이해가되지 않습니다. '사용자 관리'에 대한 사양이 너무 복잡하여 전체 팀이 너무 바빠서 인증을 수행 할 시간이 없다고 생각하기는 어렵습니다.

어떤 이유로 든 OAuth 2.0 과 같이 기본적으로 임의의 문자열을 사용하여 통신 합니다.


4

그것들을 두 개의 분리 된 경계 컨텍스트 (도메인 주도 디자인 용어)로 생각할 수 있습니다. 인증 컨텍스트의 "사용자"를 다른 컨텍스트의 "사용자"와 상관시키는 데 사용되는 ID 외에는 데이터를 공유해서는 안됩니다. 이들은 각각 "사용자"가 무엇인지, 비즈니스 책임을 수행하는 데 필요한 정보 만있는 자체 도메인 모델을 나타낼 수 있습니다.

도메인 모델은 실제 "사물"을 모델링하려는 것이 아니라 특정 상황 (아이덴티티 / 권한 관리 또는 인적 자원 등)에있는 것을 모델링한다는 점을 기억하십시오.


2

둘 다 사용자 개념을 가지고 있으며 서로에게 전화를 통해 사용자에 대해 이야기합니다.

또한 @soru가 말한 것에 동의합니다. 하나의 서비스가 다른 서비스의 데이터를 필요로하는 경우, 그들의 경계가 잘못되었습니다.

좋은 해결책은 @pnschofield가 생각 해낸 것입니다-서비스를 경계 컨텍스트로 취급하십시오.

간단히 말해, 공유 도메인 모델은 서비스 자율성을 없애고 마이크로 서비스 시스템을 분산 된 단일체로 만듭니다. 이것은 모놀리스보다 훨씬 나쁩니다.

따라서 여전히 해결되지 않은 일반적인 질문이 있습니다. 서비스 또는 컨텍스트 경계를 정의하는 방법은 높은 응집력과 느슨한 결합 성으로 번성합니다.

컨텍스트를 비즈니스 기능으로 취급하는 솔루션을 생각해 냈습니다. 높은 수준의 비즈니스 책임, 비즈니스 기능으로 전반적인 비즈니스 목표에 기여합니다. 비즈니스 가치를 얻기 위해 조직이 걸어야하는 단계라고 생각할 수 있습니다.

서비스 경계를 ​​식별 할 때 취하는 일반적인 단계는 다음과 같습니다.

  1. 더 높은 수준의 비즈니스 기능을 식별하십시오. 일반적으로 동일한 도메인의 조직간에 유사합니다. 포터의 가치 사슬 모델을 확인하는 것과 같은 느낌을 얻을 수 있습니다 .
  2. 각 기능 내에서 하위 기능을 심층적으로 파악하고 식별하십시오.
  3. 기능 간의 통신에 유의하십시오. 조직이하는 일을보십시오. 일반적으로 커뮤니케이션은 기능에 집중되어 나머지는 작업 결과를 알립니다. 따라서 기술 아키텍처를 구현할 때 서비스도 이벤트를 통해 통신해야합니다. 이것은 여러 가지 긍정적 인 결과를 가져옵니다. 이 접근 방식으로 서비스는 자율적이고 응집력이 있습니다. 동기식 통신 및 분산 트랜잭션이 필요하지 않습니다.

아마도이 기술 의 예가 당신에게 흥미로울 것입니다. 이 방법이 정말 수익성이 높으므로 주저하지 말고 의견을 보내주십시오. 물론 당신에게도 효과가 있습니다.


1

마이크로 서비스는 "아무것도 공유하지 않는"것이 아니라 "가능한 한 적은 것을 공유"하는 것입니다. 대부분의 경우 "사용자"는 실제로 공통적 인 엔터티입니다 (사용자가 일부 공유 식별자 (userId / email / phone)로 식별되기 때문에). 이러한 종류의 엔티티는 정의에 의해 공유됩니다. 사용자 모델이 범위를 벗어난 마이크로 서비스입니다. 따라서 User (가장 일반적인 필드) 만 배치해야하는 전역 스키마가 있어야합니다. 엄격한 경우에만 ID입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.