0

우리 프로젝트는 DDD를 사용하여 개발되었습니다. 우리는 사용자 신원을 확인하고 토큰을 발급 및 유효화하는 데 사용되는 단일 마이크로 서비스로 사용자 신원을 이동하기로 결정했습니다.사용자 등록시 궁극적 인 일관성

계정과 사용자가 사용자 및 계정 세부 정보를 처리하는 문제를 해결하는 다른 마이크로 서비스에 있기 때문에 궁극적 인 일관성이라는 문제가 발생했습니다.

계정에 대한 계정/사용자를 먼저 생성하고 사용자 마이크로 서비스에 이벤트를 게시하거나 이벤트를 사용자 ID 마이크로 서비스에 게시해야합니다.

첫 번째 경우에는 계정과 사용자의 기본 정보를 즉시 사용할 수 있지만 최종 일관성 지연으로 인해 토큰을 제공 할 수 없기 때문에 사용자는 로그인 할 수 없습니다.

두 번째 경우 사용자가 로그인 할 수 있지만 사용자가 계정에 로그인하면 최종 일관성 지연으로 인해 계정 정보를 사용할 수 없습니다. 이 경우 사용자가 등록 및 로그인을 확인할 수 있도록 최종 일관성이 충족 될 때 확인 메일을 보냅니다.

의견을 듣고 싶습니다. 어떤 경우가 더 의미가 있으며,이 시점에서 어떤 문제가 있습니까?

+2

나는 정체성에서 분리 된 사용자가 다소 이상하다고 생각합니다. '사용자'는 일반적으로 ID BC에서 발견되는 개념입니다. 어쨌든, 사용자가 자신의 ID로만 로그인하면 핵심 시스템 기능을 사용할 수 있습니까 (계정 정보에 분명히 액세스하는 것을 제외하고)? – plalx

답변

0

최종 일관성 지연이 필요하지 않습니다. 모든 부품이 완료되면 regiatrationCompleted 이벤트가 발생해야합니다. 이 이벤트는 귀하의 인터페이스가 반응하고 환영 전자 메일 및 이와 유사한 조치를 트리거합니다.

서로 다른 마이크로 서비스가 동시에 이벤트를 처리 할 수 ​​있으므로이 registrationCompleted 이벤트를 발생시키는 시간은 매우 짧아야합니다.

계정 정보없이 로그인하는 것은 특정 권한을 가진 계정이나 잠긴 계정과 같은 보안 문제가 발생할 수 있으므로 모든 옵션 중에서 최악입니다.

또한 마이크로 서비스는 가능한 한 작으며 크기는 작지 않습니다. 당신이 합리적으로 분할 사건을 처리 할 수 ​​없다면 당신은 너무 작게 만들었습니다.

1

망치가있는 경우 모든 것이 못처럼 보입니다. 당신이 그것을 보증하지 않는 문제에 웅장한 아이디어를 적용하기에는 너무 열심히 노력하고있는 것처럼 보입니다.

DDD를 사용할 때 문제가 발생하면 전략적 DDD 즉 설계 부분에 대해 생각하는 것이 중요합니다. 제한된 컨텍스트 (Bounded Context)는 특정 언어가 존재하며 특정 비즈니스 기능에 링크 된 구현으로 나타납니다.

이제 각 BC를보고 해당 상황에 적합한 아키텍처의 유형을 판단하십시오. 전체 시스템은 동일한 구현을 수행하지 않아야한다고 말하면 안됩니다. account \ login 생성을위한 마이크로 서비스가 정말로 필요합니까? CRUD와 같은 구현으로 벗어날 수있는 것처럼 들리지만 도입 한 최종 일관성 문제를 제거하십시오.

간단하게 유지하십시오.

+0

그래서 기본적으로 당신은 일을 간단하게 유지하기 위해 가장 높은로드 마이크로 서비스 (사용자 신원)를 계정 및 사용자 ms와 병합해야한다고 말하고 있습니까? 나는 단지 제대로 확장 할 수 있기를 원했습니다. 나는 CRUD가 마이크로 초일 수 없다고 당신이 알아 차렸습니다.나는 그것이 거짓 진술이라고 생각한다. – mko