건축 관련 질문

Question

이전 게시물 (Architecture: simple CQS)의 결과로 나중에 확장 할 수있을만큼 유연한 간단한 시스템을 어떻게 구축 할 수 있었는지 생각해 왔습니다.

다른 말로하면 : 나는 지금 본격적인 CQRS에 대한 필요성을 알지 못하지만, 필요할 경우 나중에 쉽게 진화하기를 원합니다.

그래서 저는 명령에서 명령을 분리하려고 생각했지만 동일한 데이터베이스를 기반으로했습니다.

쿼리 부분은 쉬울 것입니다. 뷰를 기반으로하는 WCF 데이터 서비스는 데이터를 쿼리하기 쉽습니다. 특별한 것은 없습니다.

명령 부분이 더 어려워서 여기에 아이디어가 있습니다. 물론 명령은 비동기 방식으로 실행되므로 결과를 반환하지 않습니다. 하지만, 내 ASP.NET MVC 사이트의 컨트롤러 (예 : 구성원의 등록 성공 여부) 명령에서 피드백을 종종 필요합니다. 따라서 컨트롤러가 명령을 보내면 명령 등록 정보와 함께 전달 된 트랜잭션 ID (guid)도 생성됩니다. 명령 서비스는이 명령을 받고 상태 '처리 중'인 데이터베이스의 트랜잭션 테이블에 넣고 실행됩니다 (DDD 원칙을 사용하여). 실행 후 거래 테이블이 업데이트되어 상태가 '완료'또는 '실패'가되며 생성 된 기본 키와 같은 기타 자세한 정보가 표시됩니다.

한편 사이트에서는 QueryService를 사용하여 'completed'또는 'failed'를 수신 할 때까지이 트랜잭션의 상태를 폴링 한 다음이 결과를 기반으로 작업을 계속할 수 있습니다. 트랜잭션 테이블이 폴링되고 결과가 'completed'또는 'failed'이면 항목이 삭제됩니다.

부작용은 내 엔터티에 대한 키로 guid를 필요로하지 않기 때문에 성능과 크기에 좋은 점입니다.

대부분의 경우이 폴링 메커니즘은 필요하지 않지만 필요할 경우 가능합니다. 또한 인터페이스는 CQS를 염두에두고 설계되었으므로 미래를 위해 열려 있어야합니다.

이 접근법의 결함이 있습니까? 다른 아이디어 또는 제안?

감사합니다.

룻

Answer 1

당신이 당신의 접근 방식과 전체 CQRS 시스템에 매우 가까운 생각합니다.

나는 당신이 묘사하고있는 것과 비슷한 것을하기 위해 사용했던 사이트를 가지고 있습니다. 내 사이트 인 braincredits.com은 CQRS를 사용하여 구성되었으며 모든 명령은 본질적으로 비동기입니다. 결과적으로 항목을 만들 때 명령에 대한 응답이 이 아닌 (처리되지 않은 것) 이외에는 사용자에게 실제로 전달되지 않습니다.

하지만 사용자가 더 많은 항목을 제출할 때 변경해야하는 사이트의 사용자 점수 ("크레딧 수")가 있습니다. 하지만 사용자가 F5를 눌러 브라우저를 새로 고치지 않게하고 싶습니다. 그래서 저는 여러분이 제안하고있는 것을하고 있습니다 - 저는 AJAX 호출을 사용하여 매 2 ~ 2 초마다 사용자의 신용도가 변경되었는지 확인합니다. 그럴 경우 새 금액이 다시 가져오고 UI가 업데이트됩니다 (사용자의 시선을 사로 잡기위한 약간의 애니메이션이 있지만 너무 화려하지는 않습니다).

사용자가보고있는 응용 프로그램의 상태가 궁극적으로 시스템 데이터 (기록 시스템)와 일치한다는 궁극적 인 일관성입니다. 이 개념은 CQRS의 핵심입니다. 제 의견으로는 많은 의미가 있습니다.시스템에서 데이터를 검색하는 즉시 (CQRS 기반이든 아니든) 데이터는 오래되었습니다. 그러나 당신이 가정하고 클라이언트가 결국 일관성이 있다고 가정한다면, 당신의 접근 방식이 타당하며,이를 고려하여 UI를 설계하고이를 활용할 수도 있습니다.

제안 사항까지, 나는 당신이 얼마나 많은 폴링을하고 얼마나 많은 데이터를 보내고 있는지를 볼 것입니다. 당신이 아닌 것처럼 소리가 나는 폴링과 함께 해 가야합니다. 그러나 귀하의 사이트에서 정기적으로 업데이트해야하는 대상을 지정하면 귀하가 잘 될 것이라고 생각합니다.

질의면에 대한 WCF 데이터 서비스 계층은 좋은 아이디어입니다. 단지 읽기 전용으로 설정되어 있는지 확인하십시오 (내가 수행 한 작업).

그 외에는 좋은 출발을하는 것처럼 들립니다.

이 정보가 도움이되기를 바랍니다. 행운을 빕니다!