마이크로 서비스에서 데이터베이스 이주 스크립트 및 API 코드에 대해 별도의 코드 저장소를 갖는 것이 이치에 맞습니까?

Question

bounded context에 따르면, 우리는 두 개의 마이크로 서비스 구현을 확인했으며 각각 Service A 및 Service B이라고 부를 수 있습니다. 이러한 마이크로 서비스는 각각 다른 리포지토리를 가지고 있습니다 (단일 책임 및 더 나은 소유권의 이점으로 인해). 이제는 각각의 리포지토리가 고유 한 데이터베이스 스키마를 사용합니다 (지속성을 더 잘 분리하고 DB 인스턴스의 유지 관리를 줄이기 위해 선택).

이전에 우리는 별도의 단일 저장소 (Service A 및 Service B의 스키마 용 스크립트 포함)에 데이터베이스 마이그레이션 스크립트를 추출하고 CI 아래의 단일 작업으로 실행했습니다. 우리가 더 많은 이야기를 태클로 이제, 우리는 몇 가지 도전에 직면 시작, 일부는 아래에 나열되어 있습니다 : 하나의 스키마에

• 의 변화는 전체 데이터베이스의 빌드를 트리거 따라서 하류 모든 microservices의 트리거, 따라서 우리의 피드백 시간을 증가
• 스키마 변경도에서 각각의 변화를 필요로하기 때문에 우리는 true 연속 전달을 달성하기 위해 일반적으로 실패에있는 Service 코드 따라서 신중한 노력은 모두 PRs
• 는 또한, 거기에 배포하는 촬영 Users과 같은 일반적인 테이블은 두 스키마 모두 현재 복제되고 있습니다.

그래서 의심의 여지 내 질문/:

• 우리는 심지어 단지 서비스처럼, 스키마에 따라 DB 마이그레이션 저장소를 분리해야합니다.
• DB 마이그레이션 스크립트를위한 별도의 저장소가 있어야합니까? 우리는 그들 각각의 Service 리포지토리 코드 내에 클럽을 운영해야합니까?
• 우리는 공통의 테이블이 더 a level up 및 Eventual Consistency

에 대한 모든 포인터/조언 것 크게 help.Thanks을 Domain Events를 제기 추출해야합니다.

Answer 1

각 코드 저장소로 마이그레이션을 유지하는 것이 좋습니다. 서비스 A에는 서비스 B와 독립적 인 고유 한 마이그레이션 세트가 있어야합니다. 그러면 서비스 A를 배포하고 서비스 B에 관계없이 A의 스키마를 마이그레이션 할 수 있습니다.

또한 공통 테이블이없는 것으로 고려해야합니다. 공통 테이블에는 심각한 단점이있을 수 있습니다. 서비스 A가 서비스 B를 중단시키는 방식으로 사용자를 수정해야하는 경우 분산 모노 리지를 작성했습니다.

---

UPDATE 1 :

강력한 참조 무결성을 필요로하지 않을 수 있습니다 감사 로그를 구축. 대신에 부드러운 외래 키를 고려할 수 있습니다.

마이크로 서비스를 디자인하는 방법은 대부분 도메인을 사용합니다. User이 인증 된 사용자 인 경우 먼저 인증의 교차 관심사를 해결해야합니다. 각 마이크로 서비스에 대해 jwt와 같은 인증 토큰을 요구하여 인증 된 사용자가 누구인지 그리고 어떤 조치를 수행 할 권한이 있는지 여부를 결정할 수 있습니다.그런 다음 감사 로그에서 사용자의 ID를 사용할 수 있습니다.

사용자가 "서비스의 제한된 컨텍스트에 속하는지"여부에 대해서는 그렇지 않습니다. 즉, User에 대한 업데이트가 Service A에 바인딩 된 이유는 무엇입니까? 사용자가 서비스 A에 종속되지 않는다고 생각하거나 서비스 A에 대한 조치를 통해 사용자를 업데이트하려고하지 않을 것입니다.