Command 자체에서 메소드를 처리하는 대신 클래스 CommandHandler를 Handle ()로 분리하는 이유

다음 과 같이 S # arp 아키텍처를 사용하여 CQRS 패턴의 일부를 구현 했습니다.

public class MyCommand
{
    public CustomerId { get; set; }

    // some other fields
}

public class MyCommandHandler<MyCommand> : ICommandHandler<MyCommand, CommandResult>
{
    Handle(MyCommand command)
    {
        // some code for saving Customer entity

        return CommandResult.Success;
    }
}

왜 Command데이터 와 처리 방법 을 모두 포함하는 클래스 가 없는지 궁금합니다 . 명령 속성과 별도로 명령 처리 논리를 테스트해야하는 일종의 테스트 가능성 이점이 있습니까? 또는 다른 구현으로 하나의 명령을 처리 해야하는 비즈니스 요구 사항이 자주 ICommandHandler<MyCommand, CommandResult>있습니까?

재밌는 질문입니다.이 질문은 엔지니어 중 한 명과 제가 작업하고있는 통신 라이브러리에 대해했던 것과 똑같은 대화를 상기시켜주었습니다.

명령 대신 Request 클래스가 있었고 RequestHandlers가있었습니다. 디자인은 당신이 묘사 한 것과 매우 흡사합니다. 혼동의 일부는 영어 단어 "command"를보고 즉시 "verb, action ... 등"을 생각한다는 것입니다.

그러나이 디자인에서는 명령 (또는 요청)을 문자로 생각하십시오. 또는 우편 서비스가 무엇인지 모르는 사람들은 전자 우편을 생각하십시오. 그것은 단순히 내용이며, 그 내용이 어떻게 행동해야 하는가와 분리되어 있습니다.

왜 이렇게 하시겠습니까? 대부분의 간단한 경우, 명령 패턴은 이유가 없으며이 클래스가 직접 작업을 수행하도록 할 수 있습니다. 그러나 동작 / 명령 / 요청이 일정 거리를 이동해야하는 경우 디자인 에서처럼 분리를 수행하는 것이 좋습니다. 예를 들어, 소켓 또는 파이프, 또는 도메인과 인프라 사이. 또는 아키텍처에서 명령이 지속적이어야합니다 (예 : 명령 처리기는 일부 시스템 이벤트, 200 개의 명령이 도착하고 처음 40 개의 프로세스가 종료 된 후 한 번에 1 개의 명령을 수행 할 수 있음). 이 경우 간단한 메시지 전용 클래스를 사용하면 메시지 부분 만 JSON / XML / binary / 무엇으로 직렬화하고 명령 처리기가 처리 할 준비가 될 때까지 파이프 라인에 전달하는 것이 매우 간단 해집니다.

CommandHandler에서 Command를 분리 할 때의 또 다른 장점은 이제 병렬 상속 계층 구조 옵션이 있다는 것입니다. 예를 들어, 모든 명령은 직렬화를 지원하는 기본 명령 클래스에서 파생 될 수 있습니다. 그리고 유사성이 많은 20 개 중 4 개의 명령 핸들러가있을 수 있습니다. 이제 처리기 기본 클래스에서 파생 할 수 있습니다. 한 클래스에서 데이터 및 명령 처리를 수행해야한다면 이러한 유형의 관계는 빠르게 제어 할 수 없게됩니다.

디커플링의 또 다른 예는 명령에 입력이 거의 필요하지 않은 경우 (예 : 2 개의 정수 및 문자열) 처리 논리가 복잡하여 중간 멤버 변수에 데이터를 저장하려는 경우에 복잡 할 수 있습니다. 50 개의 명령을 대기열에 넣는 경우 모든 중간 저장소에 메모리를 할당하지 않으려 고 CommandCommand와 Command를 분리합니다. 이제 50 개의 경량 데이터 구조를 큐에 넣고 더 복잡한 데이터 스토리지는 명령을 처리하는 CommandHandler에 의해 한 번만 (또는 N 핸들러가있는 경우 N 번) 할당됩니다.

일반적인 명령 패턴 은 단일 클래스에서 데이터와 동작을 갖는 것입니다. 이런 종류의 '명령 / 처리기 패턴'은 약간 다릅니다. 일반적인 패턴과 비교할 때 유일한 장점은 명령이 프레임 워크에 의존하지 않는다는 이점이 있습니다. 예를 들어, 명령에 DB 액세스가 필요할 수 있으므로 일종의 DB 컨텍스트 또는 세션이 있어야합니다. 즉, 이는 프레임 워크에 따라 다릅니다. 그러나이 명령은 도메인의 일부일 수 있으므로 Dependency Inversion Principle 에 따라 프레임 워크에 의존하지 않기를 원합니다 . 동작에서 입력 및 출력 매개 변수를 분리하고 디스패처를 연결하여이를 해결할 수 있습니다.

반면에, 당신은 상속과 명령 구성의 이점을 잃게 될 것입니다. 그것이 진정한 힘이라고 생각합니다.

또한 작은 이쑤시개. 이름에 Command가 있다고해서 CQRS에 포함되지는 않습니다. 그것은 훨씬 더 근본적인 것입니다. 이런 종류의 구조는 명령과 쿼리로 동시에 제공 될 수 있습니다.