마이크로 서비스 및 경계 문맥

Question

질문을 위해서, 내가 2 개의 마이크로 서비스를 가지고 있다고 가정 해 봅시다.

나는 각 microservice이 밀접하게 결합되지 않아야 함을 알고 그것 자체 데이터베이스의이 있어야 회계

• ID 관리
• .

  계정에 인보이스가 있고 각 인보이스에 발급 에이전트가 있다고 가정 해 보겠습니다. 계정에서 대행자도 ID 마이크로 서비스의 사용자로 존재합니다.

  ID 관리 (사용자)의 데이터를 회계 (상담원)에 복사해야하며 해당 경계 컨텍스트 (이름 및 성)에 필요한 데이터 만 복사해야하므로 송장에 적절한 issuingAgentId.

  데이터를 일관성있게 유지하고 컨텍스트간에 공유하는 올바른 방법입니까? 사용자가 ID 마이크로 서비스에서 생성 될 때마다 이벤트 "UserCreated"가 게시되고이 이벤트에 관심이있는 회계 또는 기타 서비스는 해당 에이전트를 추가하여 수신하고 처리해야합니까? 사용자 정보를 업데이트하는 경우에도 마찬가지입니다.

Answer 1

이 방법을 사용하여 일반적으로 선호하는 방법입니다. 다른 서비스의 데이터 사본을 보유하고있는 서비스에 로컬로 캐시를 유지합니다. 이벤트 중심 시스템에서는 관심있는 이벤트를 듣고이를 사용하여 로컬 캐시를 업데이트해야합니다. 캐시는 메모리에 있거나 지속될 수 있습니다. 유스 케이스의 예는 인보이스를 발행 할 때 회계 컨텍스트가 인보이스를 작성하기 전에 사용자/에이전트 ID에 대한 로컬 캐시를 조사하는 것입니다.

다른 옵션 :

공유 데이터베이스

나는 그것 (좋은 이유) 눈살을 찌푸리게 알고하지만 당신은 항상 데이터베이스 스키마를 공유 할 수 있습니다. 예를 들어 Identity 컨텍스트는 사용자 테이블에 쓸 수 있으며 Accounting 컨텍스트는 송장에 넣을 AgentId가 필요할 때이를 읽을 수 있습니다. 단점은 데이터베이스 수준에서 결합하고 단일 실패 지점을 도입한다는 것입니다.

당신이 정보를 필요로 할 때 당신은 다른 서비스에 RPC 호출을 할 수

RPC. 예제에서 회계 컨텍스트는 송장을 제기하기 전에 AgentId/User 정보에 대한 Identity Management 컨텍스트를 호출합니다. 이 접근법과의 절충은 다시 다른 서비스와의 결합입니다. 사용할 수 없을 때 무엇을합니까? 인보이스를 발행 할 수 없습니다.

도메인

또 다른 옵션은 다른 서비스에서 데이터를 수신하고 UI를보기 모델을 유지하는 완전히 별도의 서비스를하는 것입니다보고. 이렇게하면 다른 서비스가 다른 서비스를 염려하지 않게됩니다. 이벤트 중심 시스템을 사용할 때 UI에 대한 뷰 모델을 구축 할 수있는 다른 서비스의 이벤트를 수신합니다. 수행중인 모든 작업이 데이터를 보는 경우 일반적으로 좋은 옵션입니다.