Interface IEvent<TAuthenticationToken>
An IEvent<TAuthenticationToken> represents something that took place in the domain. They are always named with a past-participle verb, such as OrderConfirmed. It's not unusual, but not required, for an IEvent<TAuthenticationToken> to name an IAggregateRoot<TAuthenticationToken> or IEntity that it relates to; let the domain language be your guide.
Since an IEvent<TAuthenticationToken> represents something in the past, it can be considered a statement of fact and used to take decisions in other parts of the system.
Inherited Members
Namespace: Cqrs.Events
Assembly: Cqrs.dll
Syntax
public interface IEvent<TAuthenticationToken> : IMessageWithAuthenticationToken<TAuthenticationToken>, IMessage
Type Parameters
Name | Description |
---|---|
TAuthenticationToken |
Remarks
What does a ICommand<TAuthenticationToken> or an IEvent<TAuthenticationToken> look like?
An ICommand<TAuthenticationToken> or IEvent<TAuthenticationToken> is simply a data structure that contain data for reading, and no behavior. We call such structures "Data Transfer Objects" (DTOs). The name indicates the purpose. In many languages they are represented as classes, but they are not true classes in the real OO sense.
What is the difference between a ICommand<TAuthenticationToken> and an IEvent<TAuthenticationToken>?
Their intent.
What is immutability? Why is a ICommand<TAuthenticationToken> or IEvent<TAuthenticationToken> immutable?
For the purpose of this question, immutability is not having any setters, or other methods which change internal state. The System.String type in is a familiar example; you never actually change an existing System.String value, you just create new System.String values based on old ones.
An ICommand<TAuthenticationToken> is immutable because their expected usage is to be sent directly to the domain model side for processing. They do not need to change during their projected lifetime in traveling from client to server. Sometimes however business logic dictates that a decision may be made to construct a ICommand<TAuthenticationToken> and local variables should be used.
An IEvent<TAuthenticationToken> is immutable because they represent domain actions that took place in the past. Unless you're Marty McFly, you can't change the past, and sometimes not even then.
What is command upgrading?
Upgrading an ICommand<TAuthenticationToken> becomes necessary when new requirements cause an existing ICommand<TAuthenticationToken> not to be sufficient. Maybe a new field needs to be added, for example, or maybe an existing field should really have been split into several different ones.
How do I upgrade my ICommand<TAuthenticationToken>s?
How you do the upgrade depends how much control you have over your clients. If you can deploy your client updates and server updates together, just change things in both and deploy the updates. Job done. If not, it's usually best to have the updated ICommand<TAuthenticationToken> be a new type and have the ICommandHandler<TAuthenticationToken, TCommand> accept both for a while.
Could you give an example of names of some versioned ICommand<TAuthenticationToken>?
Sure.
UploadFile UploadFile_v2 UploadFile_v3
It's just a convention, but a sane one.
Also see http://cqrs.nu/Faq/commands-and-events.
Examples
public class OrderConfirmed { public Guid OrderRsn; public DateTime ConfirmationDate; }
Properties
Id
The ID of the IEvent<TAuthenticationToken>
Declaration
[DataMember]
Guid Id { get; set; }
Property Value
Type | Description |
---|---|
System.Guid |
TimeStamp
The date and time the event was raised or published.
Declaration
[DataMember]
DateTimeOffset TimeStamp { get; set; }
Property Value
Type | Description |
---|---|
System.DateTimeOffset |
Version
The version of the IEvent<TAuthenticationToken>
Declaration
[DataMember]
int Version { get; set; }
Property Value
Type | Description |
---|---|
System.Int32 |