DDD - 이벤트 명명 규칙

테스트 주도 개발(Test Driven Development, TDD)에서 "이벤트 명칭"은 테스트를 작성할 때, 특히 이벤트 주도 시스템에서 이벤트를 정의하고 명명하는 방법과 관련이 있습니다. 이벤트 명칭 규칙은 주로 코드의 가독성을 높이고 이벤트가 시스템에서 수행하는 역할을 명확하게 표현하기 위한 표준입니다. 명명 규칙은 일관성을 유지하면서 테스트 및 실제 코드에서 사용하는 이벤트의 명확한 의미를 부여하는 데 중요한 역할을 합니다. 이러한 표준화는 테스트를 더 명확하게 만들고 시스템의 의도를 파악하는 데 도움을 줍니다.

다음은 TDD에서 이벤트 명칭을 만들 때 고려해야 할 표준 규칙들입니다.

1. 이벤트 명칭은 도메인 용어를 반영해야 함

이벤트는 시스템에서 중요한 비즈니스 또는 도메인 관점의 행동이나 상태 변화를 표현해야 합니다. 이벤트 명칭은 도메인 주도 설계(DDD)의 원칙과 유사하게 도메인 용어를 기반으로 하여, 이벤트의 의도가 명확하게 드러나야 합니다.

• 예시:
  • OrderPlaced (주문이 완료된 경우)
  • PaymentProcessed (결제가 처리된 경우)
  • UserRegistered (사용자가 등록된 경우)

이처럼 이벤트 명칭은 구체적이고 직관적으로 그 행동이 무엇인지를 표현해야 합니다. 이는 테스트에서도 명확한 목적을 전달하는 데 도움이 됩니다.

2. 이벤트는 과거 시제로 명명

이벤트는 발생한 사건이나 행동을 나타내므로, 일반적으로 과거 시제로 명명합니다. 이는 이벤트가 이미 발생한 사실을 의미하기 때문에 자연스럽습니다.

• 예시:
  • OrderPlaced
  • ProductShipped
  • UserLoggedIn

이러한 과거 시제를 사용함으로써, 이벤트가 특정 상태 변화를 나타내는지 알 수 있으며, 테스트 작성 시에도 자연스럽게 이해할 수 있습니다.

3. 이벤트는 명사 + 동사의 조합으로 명확하게 표현

이벤트 명칭은 일반적으로 명사와 동사의 조합으로 구성됩니다. 이를 통해 어떤 객체가 어떤 동작을 수행했는지를 명확하게 표현할 수 있습니다. 이러한 명명 규칙은 읽기 쉽고 코드에서 무슨 일이 일어나고 있는지를 쉽게 알 수 있게 만듭니다.

• 예시:
  • CustomerSubscribed (고객이 구독함)
  • InvoiceGenerated (청구서가 생성됨)
  • SessionExpired (세션이 만료됨)

4. 도메인 내 특정 이벤트를 명확하게 구분

시스템 내 여러 이벤트가 존재할 경우, 비슷한 행동을 나타내는 이벤트라도 차별성을 두어야 합니다. 이를 통해 이벤트를 통해 발생하는 구체적인 상태 변화를 구분할 수 있습니다.

• 예시:
  • OrderShipped vs. OrderDelivered (출고와 배송 완료는 다른 상태이므로 명칭을 구분해야 함)
  • UserLoggedIn vs. UserLoggedOut (로그인과 로그아웃은 반대 동작이므로 명확하게 구분)

5. 이벤트가 트리거 되는 조건을 명확히 표현

이벤트는 주로 어떤 상태 변화나 조건에 의해 트리거되므로, 그 조건이나 이유를 명확히 반영해야 합니다. 이벤트 명칭만으로도 왜 이 이벤트가 발생했는지 명확해야 합니다.

• 예시:
  • PaymentFailed (결제 실패)
  • OrderCanceled (주문 취소됨)

이러한 명명 방식은 테스트에서 어떤 조건에서 이 이벤트가 발생하는지를 알기 쉽게 만듭니다.

6. 이벤트가 발생하는 주체를 명확히 표시

이벤트는 주로 도메인 객체의 상태 변화를 반영하므로, 이벤트의 주체가 되는 도메인 객체를 명칭에 포함하는 것이 일반적입니다. 이는 테스트 시 어떤 객체가 이벤트의 대상이 되는지를 쉽게 파악할 수 있게 합니다.

• 예시:
  • OrderPlaced (주문이 완료됨 - Order 객체가 주체)
  • PaymentAuthorized (결제가 승인됨 - Payment 객체가 주체)

7. 이벤트 명칭은 짧고 간결하게 유지

이벤트 이름은 지나치게 길거나 복잡하게 만들지 않고, 핵심 정보를 반영하는 단어들로 간결하게 작성해야 합니다. 이벤트 명칭이 지나치게 길어지면 코드 가독성이 떨어질 수 있기 때문에 적절히 줄이는 것이 중요합니다.

• 예시:
  • OrderPlacedSuccessfully 대신 OrderPlaced로 명명 (성공 여부는 이벤트의 의미상 이미 내포됨)

8. 일관성 있는 명명 규칙 유지

시스템 전반에 걸쳐 이벤트 명칭 규칙은 일관되게 적용해야 합니다. 일부 이벤트에서만 과거 시제를 사용하거나, 특정 부분에서만 명사-동사 구조를 사용하는 등의 비일관성을 피하는 것이 중요합니다. 이는 코드의 유지보수성을 높이는 데 큰 도움이 됩니다.

9. 테스트 명칭과 이벤트 명칭의 연관성 유지

TDD(Test Driven Development)에서는 이벤트와 관련된 테스트 시나리오를 작성할 때, 이벤트 명칭과 테스트 명칭 간의 연관성을 유지하는 것이 매우 중요합니다. 이를 통해 테스트 코드만 보더라도 해당 테스트가 어떤 이벤트를 다루는지 쉽게 파악할 수 있고, 테스트 목적이 분명해집니다.

테스트 명칭 작성 방식

테스트 메서드나 함수 이름에는 일반적으로 다음 두 가지 측면이 포함되어야 합니다.

1. 트리거 조건: 어떤 상태나 조건에서 이벤트가 발생하는지 설명합니다.
2. 기대 결과: 이벤트가 발생했을 때 시스템이 어떻게 동작해야 하는지 설명합니다.

이러한 방식으로 테스트 명칭을 작성하면 테스트의 목적과 시스템의 기대 동작을 한눈에 파악할 수 있습니다.

예시:

• shouldSendOrderConfirmationEmailWhenOrderIsPlaced()
  • 이 테스트는 주문이 완료될 때 주문 확인 이메일이 전송되는지 검증합니다.
  • 이벤트: OrderPlaced
  • 기대 결과: 주문 확인 이메일이 전송됨
• shouldMarkOrderAsShippedWhenShippingLabelIsGenerated()
  • 이 테스트는 배송 라벨이 생성되면 주문 상태가 "배송 완료"로 변경되는지 검증합니다.
  • 이벤트: ShippingLabelGenerated
  • 기대 결과: 주문 상태가 "배송 완료"로 변경됨

이벤트 명칭과 테스트 명칭 간의 일관성

테스트 명칭은 가능한 한 이벤트의 명칭을 그대로 반영하거나, 그 의미를 잘 표현해야 합니다. 이벤트 명칭이 도메인 지식을 반영하듯, 테스트 명칭도 도메인 지식을 바탕으로 작성됩니다. 이를 통해 테스트 코드가 도메인 논리를 명확하게 드러낼 수 있습니다.

• 이벤트 명칭: UserLoggedIn
• 테스트 명칭: shouldLoadUserDashboardWhenUserLogsIn()

이처럼 이벤트의 이름과 관련된 동작이 테스트 메서드 이름에 포함되면, 테스트의 목적을 한눈에 이해할 수 있습니다. 이는 특히 TDD 사이클에서 테스트를 빠르게 작성하고 유지보수하는 데 큰 도움이 됩니다.

---

이렇게 이벤트 명칭과 테스트 명칭의 연관성을 유지하는 것은 코드 가독성을 높이고, 테스트의 목적과 시스템 동작을 명확하게 정의하는 데 중요한 역할을 합니다.