저는 사용자 관리 Microservice (MS)를 구현하는 중이며 내가하고있는 일이 괜찮은지 확인하고 싶습니다. 사용자는 API와 상호 작용하는 UI에서 생성됩니다. API는 사용자 관리 MS에 RPC 호출을하고 CreateUserCommand를 InMem 버스에 게시합니다. 그런 다음 소비자는 DB에 사용자를 생성하여 명령을 처리하지만이 사용자도 Auth0에 등록해야합니다. 영구 대기열에 다른 명령을 보내면 구독자가 선택하게됩니다. Auth0 (Auth0에 도달 할 수없는 경우 영구 대기열)을 사용하여 해당 사용자를 등록하십시오. 성공적으로 완료되면 UserCreatedEvent를 게시 할 수 있습니까?Auth0와 통합
감사의 말을 전하면됩니다.
두 개의 경계 컨텍스트 : User management 및 Authentication이 있습니다.
User management BC는 사용자의 생명주기 (생성, 돌연변이 및 삭제)를 처리합니다. Authentication BC는 사용자가 시스템에서 자신을 식별하는 방법을 다룹니다.
따라서 사용자가 시스템에서 자신을 식별 할 가능성이없는 경우에도 사용자가 존재할 수 있다는 것은 유효한 가정입니다.
사용자 관리 BC가 CreateUserCommand을 처리 한 직후에 AUserWasCreatedEvent을 내야합니다. 그 순간 사용자가 태어 났기 때문입니다. ID가 있습니다. 이름은 UserID이므로 존재합니다.
그런 다음이 사용자 자신을 식별하는 데 평균을 필요로하고 Saga (또는 Process manager 또는 그것을 부르기 위하여 당신이 원한다 무엇 이건) 이벤트를 캐치하고 그것이 Auth0 API를 호출하여 Authentication BC로 전송하는 CreateAuth0UserCommand을 만들 수 있습니다. API는 일부 데이터로 응답하며 가능하면 token을 포함합니다. 해당 토큰은 Authentication BC로 처리되며 UserID과 연관됩니다.
Auth0을 사용하여 사용자를 등록하려면 Auth0이 내 데이터베이스의 사용자와 생성 된 사용자 ID를 묶어 둘 수 있습니다 (고유 한 응용 프로그램이 사용자 ID를 생성했음을 나타냅니다) . 그래서 토큰이 성공적으로 로그인되면 (토큰에 Auth0 userID가 포함됨) 일단 내 사용자가 내 app에서 생성 한 관련 userID를 찾아 나머지 요청에 사용하여 감사 기록 등을 만들고 싶습니다. 내 데이터베이스의 사용자에게 연결될 수 있습니다. Auth0을 내 응용 프로그램의 더 복잡한 작업에서 분리하려고 시도하고 인증을 위해 Auth0을 사용하고 있습니다.이게 합리적입니까? – CraigM
Decouple은 매우 훌륭합니다. 개념을 분리해야합니다. 인증은 사용자를 식별 만합니다. 사용자가 식별되면 인증을 받아야합니다. 그런 다음 비즈니스 논리, 핵심 도메인, 주요 초점입니다. –
사용자가 생성되어 auth0이 실패한 경우 사용자 삭제와 같은 보복 조치를 취하거나 관리자에게 알리거나 무시합니다. 이는 복잡성이 추가 된 것처럼 보이지만 디커플링에 필요합니다. –
DDD를 따르고 있습니까? (* 거의 * retorical 질문) –
또한,'Auth0'은 인간의 수동 입력이 필요합니다, 그렇죠? –
예, DDD를 따르십시오. 아니요. auth0은 사용자를 만드는 나머지 API를 제공하므로 Auth0와 상호 작용할 수 있습니다. – CraigM