답변:
Microservices 아키텍처에서 각 아키텍처는 서로 독립적이며 내부 구현의 세부 정보를 숨겨야합니다.
모델을 공유하는 경우 마이크로 서비스를 결합하고 있으며 각 팀이 제한없이 마이크로 서비스를 개발할 수있는 가장 큰 장점 중 하나와 다른 마이크로 서비스의 진화 방식을 알 필요가 없습니다. 각 언어마다 다른 언어를 사용할 수도 있다는 점을 기억하십시오.
그들이 너무 관련이 있다면 아마도 @soru가 말하는 것과 같습니다.
관련 질문 :
그것들을 두 개의 분리 된 경계 컨텍스트 (도메인 주도 디자인 용어)로 생각할 수 있습니다. 인증 컨텍스트의 "사용자"를 다른 컨텍스트의 "사용자"와 상관시키는 데 사용되는 ID 외에는 데이터를 공유해서는 안됩니다. 이들은 각각 "사용자"가 무엇인지, 비즈니스 책임을 수행하는 데 필요한 정보 만있는 자체 도메인 모델을 나타낼 수 있습니다.
도메인 모델은 실제 "사물"을 모델링하려는 것이 아니라 특정 상황 (아이덴티티 / 권한 관리 또는 인적 자원 등)에있는 것을 모델링한다는 점을 기억하십시오.
둘 다 사용자 개념을 가지고 있으며 서로에게 전화를 통해 사용자에 대해 이야기합니다.
또한 @soru가 말한 것에 동의합니다. 하나의 서비스가 다른 서비스의 데이터를 필요로하는 경우, 그들의 경계가 잘못되었습니다.
좋은 해결책은 @pnschofield가 생각 해낸 것입니다-서비스를 경계 컨텍스트로 취급하십시오.
간단히 말해, 공유 도메인 모델은 서비스 자율성을 없애고 마이크로 서비스 시스템을 분산 된 단일체로 만듭니다. 이것은 모놀리스보다 훨씬 나쁩니다.
따라서 여전히 해결되지 않은 일반적인 질문이 있습니다. 서비스 또는 컨텍스트 경계를 정의하는 방법은 높은 응집력과 느슨한 결합 성으로 번성합니다.
컨텍스트를 비즈니스 기능으로 취급하는 솔루션을 생각해 냈습니다. 높은 수준의 비즈니스 책임, 비즈니스 기능으로 전반적인 비즈니스 목표에 기여합니다. 비즈니스 가치를 얻기 위해 조직이 걸어야하는 단계라고 생각할 수 있습니다.
서비스 경계를 식별 할 때 취하는 일반적인 단계는 다음과 같습니다.
아마도이 기술 의 예가 당신에게 흥미로울 것입니다. 이 방법이 정말 수익성이 높으므로 주저하지 말고 의견을 보내주십시오. 물론 당신에게도 효과가 있습니다.
마이크로 서비스는 "아무것도 공유하지 않는"것이 아니라 "가능한 한 적은 것을 공유"하는 것입니다. 대부분의 경우 "사용자"는 실제로 공통적 인 엔터티입니다 (사용자가 일부 공유 식별자 (userId / email / phone)로 식별되기 때문에). 이러한 종류의 엔티티는 정의에 의해 공유됩니다. 사용자 모델이 범위를 벗어난 마이크로 서비스입니다. 따라서 User (가장 일반적인 필드) 만 배치해야하는 전역 스키마가 있어야합니다. 엄격한 경우에만 ID입니다.