1
DDD 및 CQRS를 기반으로 아키텍처를 설정했습니다. 또한 우리는 고객이 연결할 수있는 OAUTH 구현을 갖춘 편안한 API를 보유하고 있습니다. 고객은 API에 연결하여 클라이언트를 대신하여 작업을 수행합니다. 그들의 고객은 우리 측의 프로파일로 대표됩니다.DDD CQRS 동시 처리 문제
우리는 다음 문제에 대한 좋은 해결책이 없습니다. 클라이언트는 API에서 메소드를 호출하여 프로파일을 작성할 수 있습니다. 문제는 프로필의 고유성을 보장해야한다는 것입니다. 따라서 현재 수행중인 작업은 읽기 모델에서 기존 프로필을 확인하고, 존재하지 않는 경우 명령을 만들고, 다른 API 호출을 수행 할 수 있도록 클라이언트에 프로필 ID를 반환하는 것입니다.
클라이언트가 연속적으로 여러 번 호출을 수행하면 오래된 읽기 모델로 인해 프로파일이 한 번이 아닌 두 번 생성됩니다. 우리는 그것을 원하지 않지만 어떻게이 문제를 해결할 수 있습니까?
도메인에 둘 이상의 프로필이 생성되지 않도록하기 위해 사가를 만드는 방법에 대해 생각해 보았습니다. 요청이 동일 할 경우 동일한 프로필 ID를 클라이언트에 반환해야하기 때문에 여전히 문제가 있습니다.
의견이 있으십니까?
우리 명령은 실제로 아무것도 반환하지 않습니다. 그렇다면 고객이 API 메소드 대신 새로운 ID를 생성하도록해야한다는 것입니다. 그것은 나쁜 생각이 아닐 수도 있습니다. – TheGuest
그건 정확히 내가 말하는거야. ID가 GUID 인 경우 ID가 어디서 오는지는 중요하지 않으며 고유합니다. 행을 추가 할 때 ID를 얻기 위해 DB를 쿼리 할 필요가 없습니다. –
죄송합니다, 아마도 아직 여기 뭔가 빠졌어 .... 이벤트가 거의 동시에 발생하여 프로필이 읽기 모델에서 발견되지 않으면 도메인의 기존 GUID와 일치하는 두 번째 GUID를 어떻게 생성 할 수 있습니까? ? – swannee