 |
CQRS.NET
2.1
A lightweight enterprise framework to write CQRS, event-sourced and micro-service applications in hybrid multi-datacentre, on-premise and Azure environments.
|
|
CQRS.NET
2.1
A lightweight enterprise framework to write CQRS, event-sourced 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...
Inheritance diagram for Cqrs.Commands.ICommand< TAuthenticationToken >:Properties | |
| Guid | Id [get, set] |
| int | ExpectedVersion [get, set] |
| Properties inherited from Cqrs.Messages.IMessageWithAuthenticationToken< TAuthenticationToken > | |
| TAuthenticationToken | AuthenticationToken [get, set] |
| Properties inherited from Cqrs.Messages.IMessage | |
| Guid | CorrelationId [get, set] |
| 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.
1.8.13 