명령과 이벤트가 별도로 표시되는 이유는 무엇입니까?

명령과 이벤트가 별도로 표시되는 이유는 무엇입니까?

---

이벤트를 강조하는 아키텍처에서 명령과 이벤트의 차이점은 무엇입니까? 내가 볼 수있는 유일한 차이점은 명령은 일반적으로 시스템 외부의 액터에 의해 소싱 / 호출되는 반면 이벤트는 시스템의 핸들러 및 기타 코드에 의해 소싱되는 것 같습니다. 그러나 내가 본 많은 예제 응용 프로그램에서 서로 다른 (그러나 기능적으로 유사한) 인터페이스를 가지고 있습니다.

---

명령을 거부 할 수 있습니다.

이벤트가 발생했습니다.

이것이 아마도 가장 중요한 이유 일 것입니다. 이벤트 기반 아키텍처에서는 발생한 이벤트 가 발생한 일을 나타내는 것은 의심의 여지가 없습니다 .

이제 때문에 명령은 우리가 뭔가있다 할 일이, 및 이벤트 뭔가있는 한 우리는 이러한 것들을 이름을 지정할 때, 우리는 다른 동사를 사용한다 일어났다. 이것은 별도의 표현을 유도합니다.

명령은 일반적으로 시스템 외부의 액터에 의해 소싱 / 호출되는 반면 이벤트는 시스템의 핸들러 및 기타 코드에 의해 소싱되는 것 같습니다.

이것은 그들이 별도로 표현되는 또 다른 이유입니다. 개념적 명확성.

명령과 이벤트는 모두 메시지입니다. 그러나 실제로는 별도의 개념이며 개념은 명시 적으로 모델링되어야합니다.

---

또한 여기에 공개 된 모든 답변 외에도 이벤트 처리기는 이벤트가 발생했다는 알림을받은 후에도 명령을 트리거 할 수 있습니다.

예를 들어 고객을 생성 한 후 일부 계정 값 등을 초기화하려고한다고 가정합니다. 고객 AR이 EventDispatcher에 이벤트를 추가하고 CustomerCreatedEventHandler 객체에서이를 수신하면이 핸들러는 다음과 같은 명령의 디스패치를 ​​트리거 할 수 있습니다. 필요한 것은 무엇이든 실행합니다.

또한 DomainEvents 및 ApplicationEvents가 있습니다. 차이점은 단순히 개념적입니다. 먼저 모든 도메인 이벤트를 전달하려고합니다 (일부는 애플리케이션 이벤트를 생성 할 수 있음). 이것은 무엇을 의미합니까?

CustomerCreatedEvent가 발생한 후 계정을 초기화하는 것은 DOMAIN 이벤트입니다. 고객에게 이메일 알림을 보내는 것은 애플리케이션 이벤트입니다.

혼합하지 말아야하는 이유는 분명합니다. SMTP 서버가 일시적으로 다운되었다고해서 DOMAIN OPERATION이 영향을받는 것은 아닙니다. 여전히 집계의 손상되지 않은 상태를 유지하려고합니다.

일반적으로 Aggregate Root 수준에서 Dispatcher에 이벤트를 추가합니다. 이 이벤트는 DomainEvents 또는 ApplicationEvents입니다. 둘 다일 수 있고 그들 중 다수 일 수 있습니다. 내 명령 처리기가 완료되고 명령 처리기를 실행하는 코드로 스택으로 돌아 가면 Dispatcher를 확인하고 다른 DomainEvent를 전달합니다. 이 모든 것이 성공하면 거래를 종료합니다.

응용 프로그램 이벤트가있는 경우이 이벤트를 디스패치해야합니다. 이메일을 보낼 때 반드시 데이터베이스에 대한 개방형 연결이나 트랜잭션 범위 개방이 필요하지는 않습니다.

나는 원래의 질문에서 조금 벗어 났지만 사건이 개념적으로 어떻게 다르게 취급 될 수 있는지 이해하는 것도 중요합니다.

그렇다면 Sagas가 있습니다 ....하지만 그것은이 질문의 범위에서 WAYYYY OFF입니다 :)

말이 되나요?

---

몇 가지 예와 특히 Greg Young 프레젠테이션 ( http://www.youtube.com/watch?v=JHGkaShoyNs )을 살펴본 후 명령이 중복된다는 결론에 도달했습니다. 사용자의 이벤트 일 뿐이며 해당 버튼을 눌렀습니다. 데이터이기 때문에 다른 이벤트와 똑같은 방식으로 저장해야하며 향후보기에서 사용할지 여부를 알 수 없습니다. 사용자가 추가 한 다음 나중에 장바구니에서 해당 항목을 제거하거나 적어도 시도했습니다. 나중에 사용자에게이 정보를 상기시키기 위해이 정보를 사용할 수 있습니다.

---

그들은 매우 다른 것을 나타 내기 때문에 별도로 표현됩니다. @qstarin이 말했듯이 명령은 거부 할 수있는 메시지이며 성공하면 이벤트가 생성됩니다. 명령과 이벤트는 Dtos이고 메시지이며 생성 및 엔티티시 매우 유사하게 보이는 경향이 있지만 그 이후로는 반드시 그런 것은 아닙니다.

재사용이 걱정된다면 명령과 이벤트를 (메시지) 페이로드에 대한 봉투로 사용할 수 있습니다.

class CreateSomethingCommand
{
    public int CommandId {get; set;}

    public SomethingEnvelope {get; set;}
 }

그러나 내가 알고 싶은 것은 왜 당신이 묻는 것입니다 : D 즉, 너무 많은 명령 / 이벤트가 있습니까?

---

위에서 언급 한 개념적 차이점 외에도 일반적인 구현과 관련된 또 다른 차이점이 있다고 생각합니다.

이벤트는 일반적으로 이벤트 큐 를 폴링 해야하는 백그라운드 루프에서 처리됩니다 . 이벤트 처리에 관심이있는 모든 당사자는 일반적으로 이벤트 대기열 처리의 결과로 호출되는 콜백을 등록 할 수 있습니다. 따라서 이벤트 는 일대 다일 수 있습니다 .

이러한 방식으로 명령을 처리 할 필요가 없습니다. 명령의 작성자는 일반적으로 명령의 의도 된 실행자에 액세스 할 수 있습니다. 예를 들어 실행 프로그램에 대한 메시지 대기열의 형태 일 수 있습니다. 따라서 명령은 단일 엔티티를위한 것입니다 .

---

나는 quentin-santin의 대답에 추가해야 할 것이 다음과 같다고 생각합니다.

요청을 객체로 캡슐화하여 다양한 요청, 큐 또는 로그 요청으로 클라이언트를 매개 변수화하고 실행 취소 가능한 작업을 지원할 수 있습니다.

소스 .

---

이벤트는 과거의 사실이다.

명령 만을 요구하며, 따라서 거절 될 수있다.

명령의 중요한 특징은 단일 수신자가 한 번만 처리해야한다는 것입니다. 이는 명령이 애플리케이션에서 수행하려는 단일 작업 또는 트랜잭션이기 때문입니다. 예를 들어 동일한 주문 생성 명령을 두 번 이상 처리하면 안됩니다. 이것은 명령과 이벤트의 중요한 차이점입니다. 많은 시스템 또는 마이크로 서비스가 이벤트에 관심을 가질 수 있으므로 이벤트가 여러 번 처리 될 수 있습니다. 'msdn'

참고 URL : https://stackoverflow.com/questions/4962755/why-are-commands-and-events-separately-represented