2013-04-09 2 views
3

CQRS를 시작하면서 이벤트 클래스 정의가 내 명령 정의와 거의 1 : 1로 일치한다는 것을 알았습니다. 명백한 코드 반복을 제외하고는, 잘못하고있어. 이벤트가 명령과 일치하지 않는 경우가 있습니다. 그러나 많지는 않습니다.CQRS 이벤트 및 명령 일치

간단한 CUD 시나리오를 보자

명령 클래스 :

  • CreatePost
  • UpdatePost
  • DeletePost

이벤트 클래스 :

    0123을
  • CreatedPost
  • UpdatedPost

  • DeletedPost이에 대한 조언?

    차이점이 있으면 이벤트 저장소를 사용하고 있습니다.

    감사합니다.

  • +0

    당신이 이것을 확장 할 수 있습니까? 내가 뭘 잘못하고 있는지 알아 내려고 노력하고 있습니다. * 왜 틀린 것이 있다고 생각하니? –

    +1

    거의 이점이없는 코드를 완전히 복제하고있는 것 같습니다. – Jeff

    답변

    5

    일반적으로 CRUD 시나리오에는 CQRS가 사용되지 않습니다. CRUDy 응용 프로그램을 만드는 간단한 도구와 패턴이 있습니다.

    CQRS는 이 아니며 동작, 읽기, 업데이트, 삭제이 아닌 동작이 많은 시나리오에 많은 이점을 제공하지만 실제 동작과 유사합니다. 예 : PromoteEmployee 또는 BlacklistVendor.

    행동이 많은 도메인을 모델링하기 시작하면 여전히 많은 코어 라이팅 명령/이벤트가있을 수 있지만 나쁜 일은 아닙니다.하지만 명령과 결과 이벤트가 매우 다를 수 있습니다. 크기 (포함 된 데이터) 및 숫자.

    +0

    나는 위의 것을 사소한 예로서 사용했다. 위의 CUD 연산은 더 복잡한 명령을 포함하는 더 큰 제한된 컨텍스트의 일부입니다. 거기에서도 내 이벤트가 주로 내 명령을 반복하는 것으로 나타났습니다. – Jeff

    +3

    @Jeff 여전히 나쁜 것은 아닙니다. 그 일이 일어나기를 원한다면 (명령), 그런 일이 발생했습니다 (사건). 많은 경우에 이러한 종류의 복제는 단지 현실을 반영한 것입니다. 재사용과 같은 것을 도입하는 것은 시스템의 부분을 분리하는 아이디어와 모순되기 때문에이 경우에는 의미가 없습니다. –

    +0

    @ 제프 (Jeff) 당신이 CRUD를 당신의 모범으로 선택한 것은 유감 스럽습니다. 그것은 정말로 대화를 탈선 시켰습니다. –

    1

    Dennis Traub의 답변에 약간을 추가하기 위해 CQRS는 코드를 구조화하는 방법을 확장하여 스펙의 영역, 즉 UI의 작동 방식을 확장합니다. 모든 UI가 CQRS와 친숙하지 않습니다. 너는 Task-based-UI's rather than CRUD-y UI's의 선에 더 많은 것을 원한다.

    CRUD-y UI로 시작하면 CQRS를 적용 할 때 좌절감을 느낄 수 있습니다.

    +1

    아주 좋은 지적 –

    관련 문제