[RabbitMQ] Rabbit MQ의 이름 짓기

개발자에게 가장 중요한 역량은 "이름 짓기"이다.

 

이름을 잘 지어둬야 나중에 읽을 때 빠르고 헷갈리지 않게 읽을 수 있기 때문인데,

 

RabbitMQ 사용 시에는 이름을 지어야 할 부분이 세 군데나 있다.

 

생산자 선언

• Exchange
• Routing Key

소비자 선언

• Queue
• Binding key (routing key에 의존적)

나는 딱히 이름 짓기에 재능이 없어서 매번 AI에게 도움을 많이 받는데, 적어도 이름을 짓는데 어느정도 규칙이 있어야 나중에 읽을 때 무리가 없기 때문에, 각각의 수행하는 역할과 책임에 집중해서 이름을 짓는 규칙을 정해본다.

과거 scheduleMemberNestedDtoMap 이라는 해괴한 이름을 짓고 팀원에게 쓴소리를 들은적도 있었다...

 

---

기본적으로 위 세 요소는 각각 다음과 같은 역할을 수행한다.

Exchange

Exchange를 선언하는 코드. 주로 생산자 서버에 존재하게 된다.

• Exchange는 생산자가 실제로 RabbitMQ에 메시지를 전달하기 위한 위치에 존재한다.
• 전달된 메시지가 어떻게 전달되는지를 결정하는 데 집중한다.
• 따라서 생산자의 행위에 집중하여 이름을 명명하면 좋다.
• {myboundedcontext}.{domain}.{exchangetype}

Queue

큐를 선언하는 코드. 주로 소비자 서버에 존재하게 된다.

• Queue는 RabbitMQ로부터 전달받은 메시지를 컨슈머가 가져가기 쉽도록 보관하는 데 집중한다.
• 프로듀서는 컨슈머의 큐들을 잘 모른다. 즉 Consumer와 좀 더 밀접하게 연관되어 있다.
• 따라서 소비자의 행위에 집중하여 이름을 명명하면 좋다.
• {recevierservice}.{domain-event}.{type}

Routing Key

Routing Key를 선언/사용하는 코드

 

이부분에 대해 고민이 좀 필요했다.

•  Routing Key 는 Exchange와 유사하게, 생산자의 역할에 집중해야 한다.
• 하지만 굳이 말하자면, 특정 도메인에서 발생하는 이벤트의 상세한 "행위"의 표현에 가까웠다.

따라서 다음과 같은 방식을 취했다.

• Routing Key로 해당 도메인에서 실제로 일어난 "행위"를 표현한다.
  • {domain}.{behavior/event}
• 생산자의 행위는 Exchange에서 표현하지 않고, Routing Key에서 표현한다.
  • 이는 생산자-소비자 간에 어느정도 공유되어야 하는 "행위" 개념을 공유하고,
  • Exchange는 실제로 메시지를 다른 큐에 전달하는 방식, 즉 소비자가 몰라도 되는 행위에 집중한다.

---

이렇게 규칙을 정한 덕분에 다음과 같이 바인딩 과정에서도 생산자와 소비자 간에 양방향 의존을 지울 수 있었고,

메시지 큐의 각 요소 간에 Dependency가 없는 이름을 지을 수 있었다.

 

 

추천 다음 글 - 메시징 계약 작성 (이벤트 교환 방식의 문서화 방법)

[Pinit] AsyncAPI - EDA를 향한 이벤트 교환 계약 문서 작성