이벤트 드라이브를 구축하는 응용 프로그램에 관심이 있습니까?그렇다면 한 가지 문제가 일찍 나타날 것이다.당신의 활동은 얼마나 크거나 작습니까?

이벤트 구동 시스템

시작하기 전에 이벤트 구동 시스템의 배경 지식을 소개합니다.이벤트 구동 시스템은 서로 동기화 호출을 하지 않고 메시지, 즉'이벤트'를 방송한다.다른 서비스는 이 사건들을 감청하고 자신의 속도로 처리한다.한 서비스가 감속하거나 붕괴되기 시작한다고 가정하면 다른 서비스는 아무런 문제가 없는 것처럼 계속 일할 것이다.실패한 서비스가 다시 시작되면 이벤트를 처리하고 시스템의 나머지 부분을 따라잡을 것입니다.이것은 건장한 분포식 시스템을 구축하는 좋은 방법이다. 예를 들어 마이크로서비스를 바탕으로 하는 체계 구조이다.

그렇다면, 만약 당신이 이 시스템 중의 하나를 구축하고 있다면, 당신은 어떻게 당신의 사건을 정의합니까?

모델링 이벤트

이벤트 구동 시스템을 설계할 때, 우리는 이 시스템의 변화를 초래하는 이벤트를 모델링해야 한다.이벤트는 우리의 모든 시스템/서비스 간의 변경 사항을 방송하는 데 사용되기 때문에 두 가지 기준을 충족시켜야 합니다.

표현력

유용

다시 말하면 그들은 자신의 일을 묘사하고 사용하기 쉬운 정보를 포함해야 한다.이것은 듣기보다 복잡하다. 특히 시계 구동, CRUD/ORM 스타일의 개발에서 오신다면.

입도

우리 팀에 있어서 가장 큰 문제는 사건의 입도를 확정하는 것이다.그것들은 얼마나 작아야 합니까?우리는 매번 가치 변화를 위해 행사를 한 번 개최해야 합니까?또는 우리는 대형 이벤트를 사용하여 전체 실체, 예를 들어 사용자 대상을 방송합니까?이것들은 모두 입도의 문제들이니 이 문제에 대답하기 위해서 우리는 입도의 범위를 이해해야 한다.

디자인 활동을 할 때, 당신은 스펙트럼에서 정확한 점을 선택해야 합니다.다행이다, 이 활동은 소용없어.너무 거칠고 표현력이 없어요.우리의 경험에 따르면, 너를 실수하게 할 수 있는 세 가지 방법이 있다.
1) 거칠다
2) 너무 정교하다
3) 둘 다 조금 있다

거칠다

대략적인 사건은 대형적이고 통용된다.그것들은 대량의 데이터를 포함하는 일반적인 이름을 가지고 있다.그러나 이 이름은 그다지 많은 의미를 전달하지 않기 때문에 데이터 자체를 검사해서 실제 무슨 일이 일어났는지 알아야 한다.이것은 귀하의 서비스가 이 사건들을 먼저 정탐하고 그 중의 데이터를 검사한 후에야 이 사건들이 진정으로 관심을 가지고 있는지 확인할 수 있다는 것을 의미합니다.이것은 네가 이미 일부 논리를 너의 영역에서 너의 청중으로 침투시켰다는 것을 나타낸다.

대략적인 사건

이벤트AccountStatusChanged를 예로 들면 다음과 같은 모드를 사용합니다.

AccountStatusChanged
  accountId: 12
  status: "closed"

이것은 표현력이 없기 때문에 거친 사건이다.우리의 절차는 모두 상태에 일반적인 변화가 발생하는지, 그들의 관심 상태가 특정한 값으로 변하는지에 대해 무관심하다.마케팅 서비스는 계정이 "닫혔는지", 비용 계산 서비스는 계정이 "활성화"또는 "닫혔는지에 대해 관심을 갖는다.

대략적인 이벤트 수정

이 두 값의 변화가 서로 다른 과정을 촉발하기 때문에 이를 두 개의 이산 사건으로 모델링하는 것은 의미가 있다.

AccountClosed
  accountId: 12

AccountActivated
  accountId: 12

이 두 사건은 실제 발생한 일에 배경을 제공했기 때문에 더욱 유용하다.

왜 이러지?

굵은 이벤트의 발생에는 두 가지 이유가 있습니다.

개발자들은 그 지역의 사건 수를 줄이려고 시도하여 미리 최적화하고 있다.

사건은 UI 모델에서 만들어진 것이지 분야 전문가와 토론하고 진정한 중요한 내용을 찾아내는 것이 아니다.

입도 가 너무 가늘다

세립도 사건은 작고 특정하다.그것들은 통상적으로 명칭이 매우 좋지만, 포함된 정보는 매우 적다.지나치게 세분화된 사건 자체는 쓸모가 없다. 다음에 무엇을 할지 결정하기 전에 많은 다른 사건과 결합해야 한다.만약 당신의 탐지기가 같은 시스템에서 촉발된 여러 개의 사건을 동시에 탐지한다면, 이것은 그것들의 입도가 너무 가늘다는 것을 나타낸다.

세립도 사건

다음 모드를 사용하여 다음 이벤트CustomerFirstnameChanged 및CustomerLastnameChanged를 가져옵니다.

CustomerFirstnameChanged
  userId: ...
  firstName: "Tim" 

CustomerLastnameChanged
  userId: ...
  lastName: "The Enchanter" 

이 사건들은 독립적으로 발생했는지에 대한 서비스가 없기 때문에 입도가 너무 가늘다.우리의 서비스는 고객의 현재 성명에만 관심을 가진다.그들은 이름과 성씨가 서로 다른 시간에 바뀌었는지는 상관하지 않는다. 이것은 중요하지 않다. 그들은 현재의 가치에만 관심을 갖는다.예를 들어 저희 이메일 서비스는 사용자 이름을 업데이트하기 위해 이 두 이벤트를 감청합니다.그렇습니다.그들은 진정으로 헤어질 이유가 없다.

세립도 이벤트 복원

상기 내용을 바탕으로 더 좋은 사건은CustomerNameChanged은 다음과 같은 모델을 가지고 있다.

CustomerNameChanged
  userId: ...
  firstName: "Tim" 
  lastName: "The Enchanter" 

이제 우리 청중들은 사건 하나만 들으면 일을 촉발할 수 있다. 이것은 훨씬 간단하다.

왜 이러지?

개발자가 거친 사건을 피하고 반대 방향으로 너무 멀리 가면 입도 사건이 발생한다.그러나 근본적인 원인은 똑같다. 그들이 진정으로 중요한 것이 무엇인지 찾아내기 위해 분야 전문가와 이야기를 나누지 않았고, 반대로 그들은 틀렸다.

둘 다 조금 있어요.

나는 이것이 이상하게 들리는 것을 알지만, 너도 너무 거칠고 세밀한 사건을 동시에 설계할 수 있다.이 사건들은 대량의 데이터를 포함하는 일반적인 명칭 (즉 거칠음) 을 가지고 있지만, 그 자체는 유용하지 않으며, 항상 다른 사건 (즉 입도가 너무 가늘음) 과 결합된다.그것들은 너무 거칠고 정교한 문제를 귀여운 난잡한 가방에 결합시켰다.

틀리다

CustomerFirstnameChanged
  userId: ...
  firstName: "Tim" 

CustomerDetailsChanged
  userId: ...
  lastName: "The Enchanter"
  twitterHandle: "@enchantz247"

위CustomerDetailsChanged가 문제입니다. 너무 거칠고 알갱이가 많습니다.
그것은 너무 많은 정보를 포함하고 있기 때문에 너무 거칠다.트위터 핸들 변경에 관심이 있는 서비스는 사람의 성씨에 관심이 없다.그러나 이 사건들 하나하나를 듣고 트위터 핸들이 실제로 바뀌었는지 확인해야 계속할 수 있다.엉덩이가 아프다.
그것도 너무 과립형이다.모든 인명에 관심을 갖는 서비스는 반드시 이 두 사건을 먼저 들은 후에야 상황을 전면적으로 이해할 수 있다.그것은 위의 세립도 예시와 같은 문제가 존재하고 거칠고 표현성이 낮은 사건 명칭 문제도 존재한다.또 엉덩이 아파.

옳다

분명히 우리의 데이터 경계가 틀렸다.우리는 잘못된 사건에 데이터를 가지고 있으며, 우리의 사건의 이름은 매우 나쁘다.그것들을 다시 정의합시다.

CustomerNameChanged
  userId: ...
  firstName: "Tim" 
  lastName: "The Enchanter" 

CustomerTwitterHandleChanged
  userId: ...
  twitterHandle: "@enchantz247"

이런 활동들은 소비하기 더욱 쉽다.모든 관심 이름의 서비스는 하나의 사건만 정탐하고 트위터 핸들에 관심 있는 서비스와 같다.복잡성이 크게 낮아지고 선명도가 크게 높아진다.

왜 이러지?

시스템의 새로운 데이터를 처리해야 할 때, 이런 상황이 발생할 뿐만 아니라, 매우 나쁘게 처리될 수도 있다.새 이벤트를 추가하고 싶지 않으므로 이 데이터 세그먼트를 기존 이벤트에 추가하기만 하면 됩니다. 이 이벤트는 이미 세분화되었습니다.이것이 바로 사건의 입도 문제를 가능한 한 빨리 해결하는 것이 중요한 이유입니다. 이것은 명확성을 가져오고 더 큰 실수를 저지하는 것을 막습니다.

그럼, 당신은 어떻게 가장 좋은 점을 찾습니까?

우리는 어떻게 적당한 사건의 입도를 찾습니까?우선, 우리는 한 걸음 물러나 분야 전문가와 실제 대화를 해야 한다.그들은 이미 한계를 알고 여러 해 동안 정보를 전달하며 무엇이 중요한지, 무엇이 중요하지 않은지, 무엇이 함께 속하는지, 무엇이 분리되어 있는지 이해해 왔다.

가장 좋은 시작 방법은 그들과 당신의 영역에 시간을 보내는 것이다.부서 (즉 서비스) 내부에서 사용되는 메시지 (즉 이벤트) 와 다른 부서의 절차를 촉발하는 데 사용되는 메시지를 찾습니다.중요한 것은 첫 ES 훈련에서 네가 옳지 않다는 것을 주의해야 한다는 것이다. 이것은 괜찮다.며칠 안에 당신의 분야 전문가와 몇 차례의 세션을 진행하면 당신의 모델에서 교체하면 더 좋은 사건을 발견하고 상술한 문제를 피할 수 있습니다.
만약 이것이 듣기에 매우 힘들지만, 당신이 인코딩을 시작하기를 원한다면, 이 말을 기억하세요.

Weeks of coding can save you days of planning.

정의가 명확하지 않은 사건이 장애를 일으키고 통증, 좌절, 납부를 지연시키는 과정이 아니라 처음부터 이 사건들을 발견하는 것이 좋다는 것이다.이것은 전기에 관한 큰 설계가 아니라 전기에 관한 큰 발견이다.이 유용하고 유쾌한 인코딩을 발견하길 바랍니다!