![]() |
CQRS.NET
4.0
A lightweight enterprise Function as a Service (FaaS) framework to write function based serverless and micro-service applications in hybrid multi-datacentre, on-premise and Azure environments.
|
People request changes to the domain by sending ICommand<TAuthenticationToken>s. They are named with a verb in the imperative mood plus and may include the IAggregateRoot<TAuthenticationToken> type, for example ConfirmOrder. Unlike an IEvent<TAuthenticationToken>, a ICommand<TAuthenticationToken> is not a statement of fact; it's only a request, and thus may be refused. (A typical way to convey refusal is to raise a specifically typed IEvent<TAuthenticationToken> stating the ICommand<TAuthenticationToken> didn't happen for a specific reason). More...
Properties | |
Guid | Id [get, set] |
The identifier of the command itself. In some cases this may be the IAggregateRoot<TAuthenticationToken> or ISaga<TAuthenticationToken> this command targets. More... | |
int | ExpectedVersion [get, set] |
The expected version number the targeted IAggregateRoot<TAuthenticationToken> or ISaga<TAuthenticationToken> is expected to be. More... | |
![]() | |
TAuthenticationToken | AuthenticationToken [get, set] |
The TAuthenticationToken of the entity that triggered the event to be raised. More... | |
![]() | |
Guid | CorrelationId [get, set] |
An identifier used to group together several IMessage. Any IMessage with the same CorrelationId were triggered by the same initiating request. More... | |
string | OriginatingFramework [get, set] |
The originating framework this message was sent from. More... | |
IEnumerable< string > | Frameworks [get, set] |
The frameworks this IMessage has been delivered to/sent via already. More... | |
People request changes to the domain by sending ICommand<TAuthenticationToken>s. They are named with a verb in the imperative mood plus and may include the IAggregateRoot<TAuthenticationToken> type, for example ConfirmOrder. Unlike an IEvent<TAuthenticationToken>, a ICommand<TAuthenticationToken> is not a statement of fact; it's only a request, and thus may be refused. (A typical way to convey refusal is to raise a specifically typed IEvent<TAuthenticationToken> stating the ICommand<TAuthenticationToken> didn't happen for a specific reason).
public class ConfirmOrder { public Guid OrderRsn; }
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 string type in is a familiar example; you never actually change an existing string value, you just create new 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.