MassTransit_계약의 작성
메시지 계약의 명명 규범
명령 모드:동사+객체
이벤트 모드:개체+동사
서로 다른 모드에서 서로 다른 키를 요구합니다
Creating a message contract
In MassTransit, a message contract is defined using the .NET type system. Messages can be defined using both classes and interfaces, however, it is suggested that types use read-only properties and no behavior.
Note
It is strongly suggested to use interfaces for message contracts, based on experience over several years with varying levels of developer experience. MassTransit will create dynamic interface implementations for the messages, ensuring a clean separation of the message contract from the consumer.
An example message to update a customer address is shown below. namespace Company.Application.Contracts { using System; public interface UpdateCustomerAddress { Guid CommandId { get; } DateTime Timestamp { get; } string CustomerId { get; } string HouseNumber { get; } string Street { get; } string City { get; } string State { get; } string PostalCode { get; } } }
A common mistake when engineers are new to messaging is to create a base class for messages, and try to dispatch that base class in the consumer – including the behavior of the subclass. Ouch. This always leads to pain and suffering, so just say no to base classes.
Specifying message names
There are two main message types, events and commands. When choosing a name for a message, the type of message should dictate the tense of the message.
Commands
A command tells a service to do something. Commands are sent (using Send
) to an endpoint, as it is expected that a single service instance performs the command action. A command should never be published.
Commands should be expressed in a verb-noun sequence, following the tell style.
Example Commands:
In MassTransit, a message contract is defined using the .NET type system. Messages can be defined using both classes and interfaces, however, it is suggested that types use read-only properties and no behavior.
Note
It is strongly suggested to use interfaces for message contracts, based on experience over several years with varying levels of developer experience. MassTransit will create dynamic interface implementations for the messages, ensuring a clean separation of the message contract from the consumer.
An example message to update a customer address is shown below.
namespace Company.Application.Contracts { using System; public interface UpdateCustomerAddress { Guid CommandId { get; } DateTime Timestamp { get; } string CustomerId { get; } string HouseNumber { get; } string Street { get; } string City { get; } string State { get; } string PostalCode { get; } } }
A common mistake when engineers are new to messaging is to create a base class for messages, and try to dispatch that base class in the consumer – including the behavior of the subclass. Ouch. This always leads to pain and suffering, so just say no to base classes.
Specifying message names
There are two main message types, events and commands. When choosing a name for a message, the type of message should dictate the tense of the message.
Commands
A command tells a service to do something. Commands are sent (using
Send
) to an endpoint, as it is expected that a single service instance performs the command action. A command should never be published. Commands should be expressed in a verb-noun sequence, following the tell style.
Example Commands:
Events
An event signifies that something has happened. Events are published (using
Publish
) using either IBus
or the ConsumeContext
within a message consumer. An event should never be sent directly to an endpoint. Events should be expressed in a noun-verb (past tense) sequence, indicating that something happened.
Example Events:
Correlating messages
There are several built-in message headers that can be used to correlate messages. However, it is also completely acceptable to add properties to the message contract for correlation. The default headers available include:
CorrelationId
An explicit correlation identifier for the message. If the message contract has a property named
CorrelationId
, CommandId
, or EventId
this header is automatically populated on Send or Publish. Otherwise, it can be manually specified using the SendContext
. RequestId
When using the
RequestClient
, or the request/response message handling of MassTransit, each request is assigned a unique RequestId
. When the message is received by a consumer, the response message sent by the Respond
method (on the ConsumeContext
) is assigned the same RequestId
so that it can be correlated by the request client. This header should not typically be set by the consumer, as it is handled automatically. ConversationId
The conversation is created by the first message that is sent or published, in which no existing context is available (such as when a message is sent or published from a message consumer). If an existing context is used to send or publish a message, the
ConversationId
is copied to the new message, ensuring that a set of messages within the same conversation have the same identifier. InitiatorId
When a message is created within the context of an existing message, such as in a consumer, a saga, etc., the
CorrelationId
of the message (if available, otherwise the MessageId
may be used) is copied to the InitiatorId
header. This makes it possible to combine a chain of messages into a graph of producers and consumers. MessageId
When a message is sent or published, this header is automatically generated for the message.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
다양한 언어의 JSONJSON은 Javascript 표기법을 사용하여 데이터 구조를 레이아웃하는 데이터 형식입니다. 그러나 Javascript가 코드에서 이러한 구조를 나타낼 수 있는 유일한 언어는 아닙니다. 저는 일반적으로 '객체'{}...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.