CQ [R] S 모델에서 명령을 얼마나 세분화해야합니까?

WCF 기반 SOA의 일부를 서비스 버스 모델 (아마도 nServiceBus)로 마이그레이션하고 일부 기본 pub-sub를 사용하여 Command-Query Separation 을 달성하는 프로젝트를 고려하고 있습니다.

SOA 나 서비스 버스 모델을 처음 접하는 사람은 아니지만 최근까지 "분리"라는 개념이 최신 데이터베이스 미러링 및 복제로 제한되었다고 고백합니다. 그럼에도 불구하고 궁극적으로 일관된 시스템 의 모든 이점을 제공 하는 동시에 많은 명백한 단점 (대부분 적절한 트랜잭션 지원이 없음)을 회피 하는 것처럼 보이기 때문에이 아이디어에 매료되었습니다 .

나는 기본적으로 ESB 아키텍처 의 전문가 인 Udi Dahan의 주제에 대해 많이 읽었습니다 (적어도 Microsoft 세계에서는).

더 많은 필드를 가진 더 큰 엔터티를 가질수록 더 많은 액터가 같은 엔터티로 작업하게되며, 주어진 시간에 무언가가 어떤 속성에 닿을 가능성이 높아져서 동시성 충돌의 수가 증가합니다.

[...]

CQRS의 핵심 요소는 사용자의 의도를 파악할 수 있도록 사용자 인터페이스 디자인을 재고하는 것입니다. 따라서 고객을 선호하게 만드는 것은 고객이 이사했거나 입수했음을 나타내는 것과 다른 작업 단위가되도록합니다. 기혼. 위에서 본 것처럼 데이터 변경에 Excel과 같은 UI를 사용한다고해서 의도를 파악할 수는 없습니다.

-Udi Dahan, CQRS 명확화

인용문에 설명 된 관점에서 그 논리를 논하기는 어렵습니다. 그러나 SOA와 관련하여 그 결정에 반대되는 것 같습니다. SOA (및 실제로 일반적인 서비스)는 네트워크 채터를 최소화하기 위해 대략적인 메시지 를 처리해야합니다 .

메시지 큐가 훌륭하고 RPC 수하물이없는 분산 시스템이 많을 때 네트워크 채터가 문제가되지 않는다는 것을 알고 있지만 문제를 완전히 해결하는 것이 현명하지 않은 것 같습니다. Udi는 거의 모든 속성 변경 (즉, 필드 업데이트)이 자체 명령이어야한다고 말하고 있습니다. 이는 한 사용자가 수백 또는 수천 개의 결합 된 엔티티와 속성을 종종 기존 방식으로 업데이트 할 수 있다는 맥락에서 상상하기 어렵습니다. 웹 서비스.

SQL Server에서 일괄 처리를 한 번 업데이트하면 매개 변수가 우수한 쿼리, 테이블 반환 매개 변수 또는 준비 테이블에 대한 대량 삽입이 제공 될 때 몇 초의 시간이 걸릴 수 있습니다. 한 번에 이러한 업데이트의 모든 일을 처리하는 속도가 느린, 천천히 천천히 , 그리고 OLTP 데이터베이스 하드웨어가 / 수평 확장 할 모두의 가장 비싸다.

이러한 경쟁 우려를 조정하는 방법이 있습니까? 내가 잘못 생각하고 있습니까? 이 문제에 CQS / ESB 환경에서 잘 알려진 솔루션이 있습니까?

그렇지 않다면, 사령부에서 세분성의 "올바른 수준"이 무엇인지 어떻게 결정합니까? 데이터베이스에서 3NF와 같은 시작점으로 사용할 수있는 "표준"이 있습니까? 신중한 프로파일 링이 잠재적으로 중요한 성능 이점을 제시 할 때만 벗어날 수 있습니까?

아니면 여러 전문가가 표현한 몇 가지 강력한 의견에도 불구하고 실제로 의견의 문제 일 수있는 것 중 하나입니까?

architecture enterprise-architecture service-bus

— 애런 aught
소스

답변:

"모든 속성 변경"주제

당신이 요점을 놓쳤다 고 생각합니다. Udi Dahan은 사용자의 의도를 명령으로 포착해야한다고 말합니다. 최종 사용자는 고객이 이동했음을 나타낼 수 있습니다. 해당 명령에 고객 식별 정보가 포함될 수있는 상황에 따라 새 주소 (거리, 거리 번호, 우편 번호 등으로 분할), 선택적으로 새 전화 번호 (이동할 때 드물지 않음) . 그것은 하나의 속성이 아닙니다. 더 좋은 질문은 "명령을 어떻게 디자인합니까?"입니다. 행동 관점에서 디자인합니다. 최종 사용자가 완료하려고하는 각 사용 사례, 흐름, 작업은 하나 이상의 명령으로 캡처됩니다. 명령에 대해 더 자세히 추론하기 시작하면 해당 명령과 함께 어떤 데이터가 자연스럽게 제공됩니다. 주의해야 할 것은 "명령을 분할해야한다는 표시 일 수 있습니다. 명령 세분성과 관련하여 그 표준 을 찾지 못하길 바랍니다 . 그래도 좋은 질문입니다!

— 이브 레이 노우트
소스

이 정의는 여전히 나에게 매우 임의적이다. CSR의 개념적 모델은 주소와 우편 번호를 함께 묶는 것과 같은 방식으로 선호 상태와 무술 상태를 함께 묶을 수 있습니다. 나는 머리카락을 나누는 것을 의미하지는 않습니다. 다른 행동인지 실제로 이해하려면 다운 스트림 효과를 예측할 수 있어야하며 ESB와 CQS 및 pub /의 전체 아이디어를 OTOH해야합니다. 하위는 당신이 하류에서 일어나는 일을 알거나 신경 쓰지 않아야한다는 것입니다. 답을 주셔서 감사합니다. 감사합니다. 지금까지 더 이상

— 깨달았다

@Aaronaught : 정의 는 임의적입니다. 명령의 세부 수준은 특정 시나리오에 적합한 것으로 간주 됩니다. 모두에게 맞는 크기는 없습니다. UI에서 사용 가능한 사례 또는 작업 또는 작업에 대한 명령 일치와 같은 몇 가지 지침이 있습니다. 또 다른 세부 명령은 덜 세부적인 명령보다 더 세부적인 명령을 선호하는 것입니다 (특히 Yves는 논리 제어 흐름으로 해석되는 데이터에 대해 경고한다고 말했듯이)- 그러나 단단하고 빠른 규칙은 없습니다. "한 명의 사용자가 수백 또는 수천 개의 결합 된 엔티티 및 속성을 잠재적으로 업데이트하는"실제 시나리오가 있습니까?

— quentin-starin

그게 요점입니다! 함께 울리지 마십시오. 행동에 따라 나눕니다! 명령 / 최종 사용자의 의도에 맞지 않는 명령에 데이터를 넣지 마십시오. 그리고 그것은 다운 스트림 시스템에 관한 것이 아닙니다.

— Yves Reynhout

@qes : 우리 시스템에는 매우 현실적이고 매우 필요한 몇 가지 시나리오가 있습니다. 가능한 한 간단하게 말하면 전체 데이터 시퀀스를 수정해야하며 이러한 시퀀스는 시퀀스로만 의미가 있습니다. 물론 그들은 일반적으로 이러한 변경 사항을 레코드별로 기록하지 않으며, 대부분의 알고리즘을 적용한 다음 몇 가지 예외를 수정합니다. 어쩌면 이것은 CQS가 시작하기에 적합한 시나리오가 아니지만 결정은 내 광범위한 질문의 일부일뿐입니다.

— Aaronaught

@qes : 충분히 공평하며, 그 자체가 해답입니다. 논리 연산의 개념 (기존 서비스가 모델링되는 방식)을 확실히 이해하고 있습니다. CQS 가 오퍼레이션 을 정의 해야하는 방법에 대한 몇 가지 규칙을 변경하는 것 같습니다 . "전통적인"SOA는 가능한 가장 거친 정의에서 시작하여 필요한 경우 추상화 사다리로 내려가는 것 같습니다. CQS에 대한 나의 이해는 지금까지 반대를 나타내며 가능한 가장 세밀한 정의에서 시작하여 RPC 또는 제어 흐름과 너무 비슷해 보이는 경우 추상화합니다.

— Aaronaught

Udi가 극복하려고하는 메시지는 CQRS가 단순한 CRUD 이상이라는 것입니다. 이 레코드를 만든 이유는 무엇입니까? 이 레코드를 왜 변경합니까? 왜 삭제 / 삭제 된 것으로 표시됩니까?

명령은 사용자가 시스템을 사용하여 수행하는 조치 / 사용 사례에 해당하며 단순히 변경을 말하는 것이 아니라 조치의 의도를 표현해야합니다. 또한 미세한 입자처럼 보일 수 있지만 처음 표시되는 것보다 훨씬 거칠 수 있습니다. 예를 들어 금 상태로의 업그레이드에는 여러 속성이 변경 될 수 있으며 여러 다른 집계가 응답하고 해당 이벤트에 대한 응답으로 변경 될 수도 있습니다.

CQRS는 서비스 계층에서 비즈니스 언어를 캡처하는 것에 관한 것이므로 UI는 금 상태 업그레이드를 수행하거나 운송 업체가 배송을 배송 할 수 없음으로 표시하거나 직원이 승진 한 경우 어떻게 될지 걱정할 필요가 없습니다. 기술 그룹의 관리자에게. 잘 기술적으로 나는 지금 이벤트 소싱에 대해 이야기하고 있지만 내 표류를 얻습니다. 더 뚜렷한 메시지가 있지만 표준 CUD보다 더 세분화 된 것은 아닙니다.

— 마이클 브라운
소스