Event & Command

1. Event & Command

핵심 차이점 : 책임과 추상화 수준

1.1 Event

• 과거에 일어난 일, 되돌릴 수 없는 것
• 발신자는 수신자에게 어떻게 반응할지 알려주지 않고 알림만 제공
• 일반적으로 다수의 Consumer가 있음
• 도메인 상태 변경

1.2 Command

• 무언가 행해지기를 바람을 의미. 해당 행위는 거부될 수 있음
• 다른 응용 프로그램에서 제공하는 기능을 호출해야 할 때 사용
• 발신자가 호출하려는 수신자의 기능이나 메소드를 지정
• 한 대상에만 지정됨

1.3 Command Handler

출처 : https://cqrs.nu/Faq/command-handlers

명령 처리기의 일반적인 단계

1. 명령 자체의 요소 Validation
2. Aggregate의 현재 상태에서 명령의 유효성을 검사합니다.
3. 유효성 검사에 성공하면 0..n개의 이벤트(1이 일반적.
4. 새 이벤트를 지속시키십시오. 이 단계에서 동시성 충돌이 있으면 포기하거나 다시 시도하십시오.

Should I do things that have side-effects in the outside world (such as sending email) in a command handler?

• No, since a concurrency conflict will mean the command handler logic will be run again. Do such things in an event handler.

출처 : https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-application-layer-implementation-web-api

1.3.1 Mediator 패턴 (in a Single microservice)

• 로깅, 유효성 검사, audit, 보안 등과 같은 추가 동작 등의 수단 제공

1.3.2 메시지 큐 활용

• 비동기식 Command가 실제 유용 & 사용되는가???

  • 출처 : https://groups.google.com/g/dddcqrs/c/xhJHVxDx2pM/m/WP9qP8ifYCwJ

  Burtsev Alexey
  읽지 않음,
  2012. 5. 9. 오후 7:56:00
  받는사람 ddd...@googlegroups.com
  I find lot's of code where people use async command handling or one way command messaging without any reason to do so (they are not doing some long operation, they are not executing external async code, they do not even cross application boundary to be using message bus). Why do they introduce this unnecessary complexity? And actually I haven't seen a CQRS code example with blocking command handlers so far, thought it will work just fine in most cases.
    
  Oddly I find this especially often in ASP .NET WEB environment, where people begin to use AJAX, e-mail, or any other back channel to inform client on command result.
  As a fresh example of this is Microsoft Patterns & Practices CQRS Journey, where they use async command handling, and then use ugly while(NotDone) blocking loop in page controller.
  

  Yevhen Bobrov
  읽지 않음,
  2012. 5. 9. 오후 9:51:13
  받는사람 ddd...@googlegroups.com
  Alexey,
    
  You're absolutely right. I see this everywhere. Similar abuse happens with Sagas.
  If you don't really need command to be executed asynchronously - don't do it.
    
  In our app we execute all user-created commands synchronously.
  The only commands which got executed asynchronously are system-generated commands.
    
  In fact I don't believe that there is such thing as asynchronous command at all, because the sending agent is usually interested in the result of its execution.
  So when the command is created as a result of user initiated action - it's exactly this case. You just execute it and immediately communicate the status back - ok or exception.
    
  The other case, is when the command got created by the system, in response to some event. Because event handling is asynchronous by nature, ie fire-and-forget, so all commands generated in response to this event will also be asynchronous as a consequence.
    
  In fact, even Greg admitted that here
    
  Yevhen
  

참조

• https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-application-layer-implementation-web-api
• Events vs. Commands in DDD
• https://medium.com/ingeniouslysimple/command-vs-event-in-domain-driven-design-be6c45be52a9
• https://github.com/gregoryyoung/m-r
• https://martinfowler.com/eaaDev/EventNarrative.html#EventsAndCommands
• https://www.enterpriseintegrationpatterns.com/CommandMessage.html
• https://www.enterpriseintegrationpatterns.com/EventMessage.html