CQRS à la Greg Young
Bertrand defines CQS as: every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer.
Greg however takes this same principle but he applies it to the whole architecture of a system, clearly separating the write side (Commands) from the read side (Queries) of the system. The write side is what we already know as the domain, containing all the behavior which is what makes the system valuable. The read side is specialized towards the specific reporting needs, think for example about the application screens that enables the users to execute domain behavior, but also any traditional reporting needs are provided by the read database.
So lets take a quick look at the overall architecture before we dive into the details:
CQRS - Overview
You have to excuse me for not using Visio to make this drawing, but I really didn’t feel like tackling yet an other layer of complexity tonight. At least I did the labels in typed text, so it is readable. I will discuss this architecture in 4 phases, the order I choose is what I believe is the natural way your would think about this. In the end you will see that the whole principle is rather simple. Really.
CQRS - Devision
1 - Queries
2 - Commands
3 - Internal Events
4 - External Events (Publishing)
In order to understand this type of architecture better I decided to build an example application; I will use this example in this post to demonstrate the different aspects of the architecture to you. The example has already been released in the wild (ok I meant the DDD group on Yahoo) and can be found here: http://github.com/MarkNijhof/Fohjin
Queries (reporting)
The first part I would like to discuss is the reporting needs of a system, Greg defines any need for data from the system as a reporting need; this includes the various application screens which the user uses to base his decisions on. This seemed like a strange statement at first, but the more I think about it the more sense it makes. This data is purely used to inform the user (or other systems) about the current state of the system in the specific context of the user so that they can make certain decisions and execute domain behavior.These reports will never be updated directly by the consumer of these reports, the data represents the state of the domain, so the domain is responsible for updating it. So all we really do on this side is report the current state of the system to who or what ever needs it.
When an application is requesting data for an specific screen than this should be done in one single call to the Query layer and in return it will get one single DTO containing all the needed data. Now because of this specific use of the data it makes sense to order and group it in such a way that is determined by the needs of the system. So we de-normalizing the data trying to make a single table reflect a single screen or usage in the client application. The reason for this is that data is normally queried many times more than domain behavior is being executed, so by optimizing this you will enhance the perceived performance of the system.
Here you may choose to use an ORM like NHibernate to facilitate the reading from the database, but considering that you would only be using a very small percentage of the capabilities of a proper ORM you may not need to go that way at all. Maybe going for Linq2Sql of even as Greg suggested using reflection to assemble the SQL statements directly from the DTO’s (using reflection and Convention over Configuration makes this rather simple) is perhaps a better solution for the problem. This will be up to you and probably depends on specific scenario and what you feel comfortable with.
In the example that I created to demonstrate this type of architecture I choose for using reflection of the DTO’s because I wanted to put the emphasis on the CQRS implementation and not on the ORM implementation.
The more traditional reporting needs will also get its own database schema and the data there will be optimized for that need as well, so in the end we will end up with quite a bit of duplication of the data, but that is all right. The process that is responsible for updating the data in the different databases will make sure that this happens in the correct way, we will go over this in a later part of this post.
Commands (executing behavior on the domain)
Lets first consider what would normally happen after receiving a DTO; the user would make changes to the data and save this back on the DTO. This DTO then gets shipped back to the back-end, converted into an entity and the ORM will make sure that the changes are persisted into the database.This would result in loosing some very valuable information; the Why did this change happen? You completely loose the intent the user had when he changed the data, and this is one of the things Greg’s implementation of CQRS is solving.
CQRS as the name indicates uses Commands, these commands are created on the client application and then send to the Domain layer. Lets take an example: A customer from a bank comes in the office and tells the person behind the desk that he needs to change his address. And instead of just getting the customer information and making the changes directly in the address fields, the bank employee firsts asks the question; Why would you want to change your address? The most likely response would be because the customer has moved, but it could also be because there is an error in his address and that all his mail ends up with his downstairs neighbor. Now these are two completely different reasons to update a customer address. Why could this be important? Well granted the example is rather silly, but lets assume the bank wants to know how many customers go to a competitor after moving? How loyal are our customers, should we keep sending them specific information after they have moved x miles away? Right this information is completely lost in our original way of working, but when using commands and events (more on events later) we maintain the original intent of the action. So after asking the question the customer answers that he has indeed moved and the bank employee selects the “Customer has moved" in the application and gets the ability to change only the address. When clicking save a CustomerMovedCommand will be created with only the changed address and is send to the domain.
We also get one other great benefit from using these commands and that is that these commands are easy to communicate with our client while building or working on the system. Because our clients would most likely use these types of behavior when explaining what they want to accomplish. Al do Greg thinks times have changed, “Our grand failure", but it should really be the case that our clients talk their own domain language. When using these commands we can start talking the same language even in the code.
That is what Domain-Driven Design is all about, instead of doing something technical like update client, it is actually describing the process that the user uses into the code like; the client has moved.
Command
1 namespace Fohjin.DDD.Commands
2 {
3 [Serializable]
4 public class ClientIsMovingCommand : Command
5 {
6 public string Street { get; private set; }
7 public string StreetNumber { get; private set; }
8 public string PostalCode { get; private set; }
9 public string City { get; private set; }
10
11 public ClientIsMovingCommand(Guid id, string street, string streetNumber, string postalCode, string city) : base(id)
12 {
13 Street = street;
14 StreetNumber = streetNumber;
15 PostalCode = postalCode;
16 City = city;
17 }
18 }
19 }
All these commands will be send to the Command Bus which will delegate each command to the command handler or command handlers. This also effectively means that there is only one entry point into the domain and that is via the Bus. The responsibility of these command handlers is to execute the appropriate behavior on the domain. Close to all of these command handlers will have the repository injected to provide the ability to load needed the Aggregate Root on which then the appropriate behavior will be executed. Usually only one Aggregate Root will be needed in a single command handler. Later we will also take a closer look at the repository as it is different from your ordinary DDD repository.
Command Handler
1 namespace Fohjin.DDD.CommandHandlers
2 {
3 public class ClientIsMovingCommandHandler : ICommandHandler<ClientIsMovingCommand>
4 {
5 private readonly IDomainRepository _repository;
6
7 public ClientIsMovingCommandHandler(IDomainRepository repository)
8 {
9 _repository = repository;
10 }
11
12 public void Execute(ClientIsMovingCommand compensatingCommand)
13 {
14 var client = _repository.GetById<Client>(compensatingCommand.Id);
15
16 client.ClientMoved(new Address(compensatingCommand.Street, compensatingCommand.StreetNumber, compensatingCommand.PostalCode, compensatingCommand.City));
17 }
18 }
19 }
As you can see a command handler has only one responsibility and that is to handle the one particular command by executing the appropriate domain behavior. The command handler should not be doing any domain logic itself. If there is a need for this than that logic should be moved into a service of its own. An example of this is in my example code is an incoming money transfer, more about that later.
Internal Events (capturing intent)
So finally we have arrived at the actual domain, the client has requested a certain view of our domain, has received the appropriate report DTO and has made a decision which resulted into a command being published. The appropriate command handler has then loaded the correct Aggregate Root and executed the appropriate domain behavior. So now what?Now we are going to separate the domain behavior from the state changes resulting from this domain behavior including the triggering of external behavior. This would not be much different from how you would do this now, first verify the normal guards, do what you have to do, but don’t set any internal state, and don’t trigger any external behavior (Ok the last part is more an optional thing to consider, state is the key here). Instead of writing these state changes directly to the internal variables you create an event and fire it internally. This event as well as the method name of the behavior should be descriptive in the Ubiquitous Language of the domain. Then the event will be handled inside the domain Aggregate Root which will set the internal state to the correct values. Remember that the event handler should not be doing any logic other then setting the state, the logic should be in the domain method.
Domain Behavior
1 public void ClientMoved(Address newAddress)
2 {
3 IsClientCreated();
4
5 Apply(new ClientMovedEvent(newAddress.Street, newAddress.StreetNumber, newAddress.PostalCode, newAddress.City));
6 }
7
8 private void IsClientCreated()
9 {
10 if (Id == new Guid())
11 throw new NonExistingClientException("The Client is not created and no opperations can be executed on it");
12 }
Domain Event
1 namespace Fohjin.DDD.Events.Client
2 {
3 [Serializable]
4 public class ClientMovedEvent : DomainEvent
5 {
6 public string Street { get; private set; }
7 public string StreetNumber { get; private set; }
8 public string PostalCode { get; private set; }
9 public string City { get; private set; }
10
11 public ClientMovedEvent(string street, string streetNumber, string postalCode, string city)
12 {
13 Street = street;
14 StreetNumber = streetNumber;
15 PostalCode = postalCode;
16 City = city;
17 }
18 }
19 }
Internal Domain Event Handler
1 private void onNewClientMoved(ClientMovedEvent clientMovedEvent)
2 {
3 _address = new Address(clientMovedEvent.Street, clientMovedEvent.StreetNumber, clientMovedEvent.PostalCode, clientMovedEvent.City);
4 }
The reason why we want these events is because they now become part of our persistence strategy, meaning that the only information we will be persisting of an Aggregate Root are the generated events. So if every state change is triggered by an event, and an internal event handler has no other logic then setting the correct state (and that means not even deriving other information from the data in the event), then what we can do then is load all historical events and have the Aggregate Root replay them all internally bringing back the original state of the Aggregate Root in exactly the same way it got there in the first place. It really is the same as replaying a tape.
One thing to note is that these events are write only, you will never add, alter or remove an event. So if you suddenly end up with a bug in your system which is generating wrong events, then the only way for you to correct this is to generate a new compensating event correcting the results of the bug. Of course you want to fix the bug as well. This way you have also tracked when the bug was fixed and when the effects of the bug where corrected.
By having this architecture we now basically solved the problem of loosing original intent, because we keep all events that have ever happened and these evens are intent revealing. An other very interesting thing is that now you have an audit log for free, because nothing will ever change state without an event and the events are stored and used in building up the Aggregate Roots they are guaranteed in sync with each other.
The Domain Repository
I mentioned before that the Domain Repository would be completely different from one that is normally the result of practicing DDD. Normally you would end up with very specific repositories allowing the request of all kinds of different information from the domain. But when using Greg’s implementation of CQRS your domain is completely write only, so the repository only has to be able to Get an Aggregate Root by its Id and it must be able to save the generated events. You also completely get rid of any impedance mismatch between the domain and the persistence layer.Domain Repository Contract
1 namespace Fohjin.DDD.EventStore
2 {
3 public interface IDomainRepository
4 {
5 TAggregate GetById<TAggregate>(Guid id)
6 where TAggregate : class, IOrginator, IEventProvider, new();
7
8 void Add<TAggregate>(TAggregate aggregateRoot)
9 where TAggregate : class, IOrginator, IEventProvider, new();
10 }
11 }
The reporting repositories on the other hand would probably look much more like the traditional repositories from DDD.
So what happens when you have 100.000 events that need to be replayed every-time you load the Aggregate Root, that will slow down your system immensely. So to counter this effect you would use the Memento pattern to take a snapshot from the internal state of the Aggregate root every x number of events. Then the repository will first request the snapshot, load that in the Aggregate Root and then request all the events that have occurred after the snapshot, bringing it back to the original state. This is only an optimization technique you would not delete events that happened before the snapshot, that would pretty much defeat the purpose of this architecture.
Data Mining
One other really interesting fact about storing all the events is that you can replay these events at a later date and retrieve important business information from them. And you get this information from the start of the system, instead having to build-in some extra logging and wait a few months for reliable data.External Events (publishing, letting others know)
Finally we are getting to the fourth part of this explanation (and I am saying this more for my own sake, pfff). So what happens here, looking back at what we have so far, we can read domain state and we can execute behavior and update the internal state of the domain. The obvious thing that is missing is a way to bring the reporting database in sync with the current state of the domain. The way we will be doing this is by publishing the internal domain events outside the domain. Then there are event handlers that pick up on those events and bring the reporting database in sync. This is a place where you could use an ORM, but in fact it is very easy to just generate the needed SQL statements and execute them.Greg actually mentioned a really nice way of caching these SQL statements, he would batch them in a single batch and execute the batch if it gets older then x seconds, or (and this is the interesting part) whenever a read request came in. So when a read request comes in this SQL statement is appended to the batch and the whole thing is executed, ensuring that the read request will always have the latest data available to that part of the system. More on this below here.
The domain repository is responsible for publishing the events, this would normally be inside a single transaction together with storing the events in the event store.
Events are also used to communicate between different Aggregate Roots, I my example I am using a transaction from one account to an other account. Here I generate an event that money is being transfered to an other account, this event will reduce the balance of the current account. Later an event handler will make the same change in the reporting database. An other event handler will actually forward the transaction to a service which checks if the target account is a local account, else forwards a money transfer to a different bank (in my example the different bank is actually the same, but via a different route). But lets assume that the money transfer goes to an internal account, in that case the service will publish a money transfer received command in the command bus and the whole process continues in a different Aggregate Root. So in this case the command is not triggered from a GUI but from a different part in the system.
There is an other interesting fact in the scenario when money is received from an other bank, because a money transfer only has the account number to identify the target account and not the Aggregate Root Id (you can’t expect foreign systems to know this, yes I know you can make this a natural Id as well) the money received service first needs to do a query to the reporting database requesting an account DTO where the account number is the same as the target account. When this is successful it will use the Id from the account DTO and put that in the command to be published.
But it doesn’t stop there, as I mentioned before you could also have events that don’t have any state change information but for example indicate that a message (Email, SMS or what ever, depends on the event handler) needs to be send to an user. And because you are using Domain Events for all this, everything will be stored in the Event Store, so you keep your history.
Eventual Consistency
Normally when beginning to implement CQRS you would start with a direct publishing mechanism so that storing the events and updating the reporting database happen in the same thread. When using this approach you have no problems with eventual consistency.But when you system starts to grow you might get some performance problems and then you could start by implementing a bus disconnecting the publishing of the events and handling of these events. This means that it is possible and likely that your event store and reporting database are not completely in sync with each other, they are eventual consistent. Which means that it is possible that the user sees old data on his screens.
Depending on how critical this really is you can have different counter measures for this, which I will be going into in a different post as this is also not something the example provides.
Specifications
The specifications that you can write using this architecture is something that I really like, what you would do is talk to your client and ask him things about how he wants his process to work. So a possible scenario could be:Withdrawing money from an account
So how would that go? Well the clients needs to have opened an account with our bank and he needs to have some money transfered on it in order to be able to withdraw money from it. And when this happens the balance of the account must be lowered to the correct amount. Ok so, given an account was opened, and a cash was deposited, when making a cash withdraw then we get a cash withdrawn event.
1 namespace Test.Fohjin.DDD.Scenarios.Withdrawing_cash
2 {
3 public class When_withdrawing_cash : CommandTestFixture<WithdrawlCashCommand, WithdrawlCashCommandHandler, ActiveAccount>
4 {
5 protected override IEnumerable<IDomainEvent> Given()
6 {
7 yield return PrepareDomainEvent.Set(new AccountOpenedEvent(Guid.NewGuid(), Guid.NewGuid(), "AccountName", "1234567890")).ToVersion(1);
8 yield return PrepareDomainEvent.Set(new CashDepositedEvent(20, 20)).ToVersion(1);
9 }
10
11 protected override WithdrawlCashCommand When()
12 {
13 return new WithdrawlCashCommand(Guid.NewGuid(), 5);
14 }
15
16 [Then]
17 public void Then_a_cash_withdrawn_event_will_be_published()
18 {
19 PublishedEvents.Last().WillBeOfType<CashWithdrawnEvent>();
20 }
21
22 [Then]
23 public void Then_the_published_event_will_contain_the_amount_and_new_account_balance()
24 {
25 PublishedEvents.Last<CashWithdrawnEvent>().Balance.WillBe(15);
26 PublishedEvents.Last<CashWithdrawnEvent>().Amount.WillBe(5);
27 }
28 }
29 }
Ok ok, but now we have the same story, only now there is not enough money on the account, then we should give an exception.
1 namespace Test.Fohjin.DDD.Scenarios.Withdrawing_cash
2 {
3 public class When_withdrawling_cash_from_an_account_account_with_to_little_balance : CommandTestFixture<WithdrawlCashCommand, WithdrawlCashCommandHandler, ActiveAccount>
4 {
5 protected override IEnumerable<IDomainEvent> Given()
6 {
7 yield return PrepareDomainEvent.Set(new AccountOpenedEvent(Guid.NewGuid(), Guid.NewGuid(), "AccountName", "1234567890")).ToVersion(1);
8 }
9
10 protected override WithdrawlCashCommand When()
11 {
12 return new WithdrawlCashCommand(Guid.NewGuid(), 1);
13 }
14
15 [Then]
16 public void Then_an_account_balance_to_low_exception_will_be_thrown()
17 {
18 CaughtException.WillBeOfType<AccountBalanceToLowException>();
19 }
20
21 [Then]
22 public void Then_the_exception_message_will_be()
23 {
24 CaughtException.WithMessage(string.Format("The amount {0:C} is larger than your current balance {1:C}", 1, 0));
25 }
26 }
27 }
The cool part here is that the whole domain is seen as a black box, you are bringing it to a certain state exactly the same way as it is used, then you publish a command just like your application would, and after that you verify that the domain publishes the correct events and that their values are correct. This means that you are never testing your domain in a state that it cannot naturally get to, which makes the tests more reliable.
Now imagine a parser that takes all the class names, underneath each class name it would print the events that occurred to get into the current state. Then you print the command that we are testing. and finally you print the method names that test the actual outcome. This would be a very nice readable specification that the client at least can understand.
Some other benefits
One last benefit I would like to highlight from using this type of architecture is how easy it is to split the work load between different team, more specifically between team with different hourly rates. The domain logic is something that needs to be right, this is where you would put your more expensive developers on, the ones that understand the business, understand good coding practices, you know what I mean. But the read side is not as important, sure it needs to be correct as well, but this is not where the value lies, this can be done quickly and in a year or two again. This is something you let the cheaper developers create, it doesn’t require much domain knowledge all that is really important is that they need to know how the GUI needs to work, what commands they can use and what events to expect.I think this is of great value for the business, something that is easily overlooked.
Finally
As you can see this is all very simple and straightforward. It is a different mindset, but once you enter this mindset you will notice that your applications will be much more behavioral versus CRUD. And hopefully our clients can move back into thinking about their business logic instead of the thinking about the CRUD way we have forced upon them. Also I would like to thank Greg Young for providing me with so much information and putting up with all my weird questions, and thank Jonathan Oliver and Mike Nichols for some improvements on the technical side.
In the case where the command sent to the domain is invalid (bad data, etc.), you thrown an exception. In general, would you catch the exception in your command handler and then publish some kind of failure notification to be picked up by the GUI or possibly the reporting side in order to notify the client of the problem?
Jonathan Oliver, Thursday, November 12, 2009 at 5:20 AM
Very good Mark. I have been waiting for the description of your example. Now the things are clear.
Register commandHandler, Thursday, November 12, 2009 at 5:36 AM
Very nice article and explanation. Although I'm not very clear on the how you retrieve the latest version in a way that makes it every bit as simple and direct as doing CRUD.
In CRUD fashion you only have one version and you get that version by using the ID. In a version based system you would always go getById and latest version. The latest version is an unknown variable from my point of view and you have to do something like count the copies of this id to give me the version.
Only after you have the latest version you get the agregate.
Am I missing something ? Or did I miss-understand.
The idea is very appealing to me and I would like to have it better explained if you can spare some minutes
Mihai, Thursday, November 12, 2009 at 8:20 AM
Very, very interesting post. I've been reading various bits and pieces and seen a couple of presentations but this is by far the most complete description I have seen so far. Thanks!
I think you have an error in the Domain Behavior code section. You write
if (Id == new Guid()) { ... }
which I imagine is extremely unlikely to be true most of the time ;-) I guess you want to check for Guid.Empty instead...
HakonB, Thursday, November 12, 2009 at 8:23 AM
Sorry, I saw the memento being mentioned and missed the memento being mentioned. I'll probably reread your post, and have a closer look at the application.
Mihai, Thursday, November 12, 2009 at 8:32 AM
Great post. I've been waiting this for a long time. But is that true 'write only' storage ?
Or write once ?
Welly Tambunan, Thursday, November 12, 2009 at 10:47 AM
Nice wrap up of the current state of CQRS !
@Welly> this is a Write once, (ie, events are inserted and read, but never updated or deleted).
thinkbeforecoding, Thursday, November 12, 2009 at 11:40 AM
@HakonB
The if (Id == new Guid()) { ... } this is the same as if (Id == Guid.Empty) { ... } I have tests proving this, but considering many people don't know this I'll change it in the post and in the code :)
@Mihai
The big difference between this and CRUD from a non technical point of view is that in CRUD you loose the original intent, where in this architecture you keep this knowledge.
@Jonathan Oliver
Yes exception throwing is a quick and easy way to communicate back to the caller something went wrong, then how you deal with this may depend on the scenario, sometimes you want this information back to the user, other times the system may be able to recover from this automatically. For example a failed transfer is corrected automatically.
Mark Nijhof, Thursday, November 12, 2009 at 11:57 AM
I'm using a database on the command side (like Udi Dahan), but I see the benefits from being able to play back the events in some cases. Thank you for a great example application and blog post. Keep up the good work :-)
Pål Fossmo, Thursday, November 12, 2009 at 1:07 PM
"the service will publish a money transfer received command in the command bus"
"then you publish a command"
I've been corrected more than once on the DDD group for using language like this. My understanding is that commands are sent and events are published. Also the command from the first quote should probably be called something like ReceiveMoneyTransfer. Nuances like these can muddy the CQRS water IMHO.
Regarding the usage of exceptions to report business rule violations, have you considered using events instead? What do you think about distinguishing domain state change events from domain fault events using a marker interface?
On a different note, great work on the sample project!
Joe, Thursday, November 12, 2009 at 2:37 PM
Awesome writeup Mark!
Thanks for your diligence in producing the sample and this article.
Mike, Thursday, November 12, 2009 at 2:45 PM
@Andy
Just contact Greg Young
@Pål Fossmo
Ok to be honest CQRS a la Greg is CQRS and Event Sourcing, both complement each other very nicely. I have to read up a bit more on what Udi describes, but I believe he is coming mostly from when you have an existing scenario.
@Joe
In my example code they have clear distinct names (I believe) I don't think I corrected you about sending and publishing, I can see why you would want to make the difference, when sending a command you know where you want it to end up, when publishing the events you don't really care who acts on them. Thanks.
-Mark
Mark Nijhof, Thursday, November 12, 2009 at 2:47 PM
I really like that you included transferring money in the sample project. So many examples only touch on simple scenarios where a single aggregate root is involved.
Money transfers could be used to show even more implementation possibilities using DDDD/CQRS/Event Sourcing. For example, instead of a domain service maybe a MoneyTransfer is actually an aggregate root. When the MoneyTransfer is submitted a saga is started which coordinates account debits and credits and handles compensating actions. If all debits and credits are successful the saga ends and the MoneyTransfer is completed. Also if the saga takes too long should the transfer be canceled?
Those are just some thoughts which may or may not be good. What do you think?
Joe, Thursday, November 12, 2009 at 3:06 PM
@Joe
When I was thinking of the example (which is rather hard to come up with a nice example) I wanted to have at least 2 AR types, honestly I didn't think about Saga's too much yet, but indeed if you would model this better then you probably end up with an AR on it's own to handle the transaction. Perhaps something to do after the E-VAN talk next week.
-Mark
Mark Nijhof, Thursday, November 12, 2009 at 3:14 PM
Great post! Finally I have a feeling I understand CQRS. Thank you so much!
Szymon Pobiega, Thursday, November 12, 2009 at 4:43 PM
Regarding AR associations, I think it is important to think in terms of the Bounded Context. When two ARs are being dealt in the same BC then I try to keep something like CreateSomeAggregate in the same transaction as CreateSomeOtherAgrregateInSameBC using smart EventHandlers.
A rule I have been working under has been this: CommandsHandlers are async, EventHandlers are synchronous. This makes Sagas essentially organizers of Commands and there is a clear division between BC's.
So far this has worked well but there may be some scenario that makes this break.
Mike, Thursday, November 12, 2009 at 6:11 PM
@Mike
That is an interesting idea, only for example the event handlers that update the reporting database may after a performance upgrade actually all become async.
I actually assume that all events are async by nature, some may be handled quicker then others but they should not be locking. The same with commands, only everything that happens within a command will be sync, which includes the domain behavior saving the events and publishing the events into the bus. But I might like the idea that when within a BC you keep it with event handlers, but when going outside the BC then the event needs to be transferred to a command. Need to think more about it :)
Mark Nijhof, Thursday, November 12, 2009 at 6:26 PM
@Mark,
Yes, I was speaking solely within the domain regarding event handlers. The sync/async event consumption within the reporting side can be kept different from the domain consumption within the configuration. Having event handlers within the domain distinct from the package of reportingEventHandlers helps this separation.
Mike, Thursday, November 12, 2009 at 6:44 PM
@Mike
Like Mark, I too assume all events are async. Handling them synchronously is probably a decision that can be made depending on your requirements. One situation where synchronous event handlers would cause some problems is if there are multiple instances of a BC deployed in a distributed fashion.
Joe, Thursday, November 12, 2009 at 6:46 PM
@Mike
Maybe I am misunderstanding you now. Do you mean that you have your events that are internal to the AR and then map these to different events as soon as the AR is saved? Because that seems like an unnecessary mapping. Also having different namespaces for different responsibilities of these events sounds wrong, this would mean that when I Apply an event I need to know what I want to happen outside of the AR, I am only concerned about what happens within the AR. Then there are the different event handlers and there I can see a strong separation to be useful.
But as I said, I might be completely mis-understanding your comment, most likely considering our previous conversations :)
Mark Nijhof, Thursday, November 12, 2009 at 7:25 PM
@Joe,
I have to think through that and I think I understand what you mean. There usually only two reasons I have an event handler within the domain (write) side:
1. Transform to a command that gets sent to another BC,
2. Some service is required to complete the behavior commanded
#1 wouldn't seem to care whether sync/async.
#2 could be problematic if async since there is an order of operations being implied. But isn't this a concurrency problem that will need to be solved in any case?
Mike, Thursday, November 12, 2009 at 7:33 PM
@mike, if an order of operation is requiered you can surely use a saga ?
thinkbeforecoding, Thursday, November 12, 2009 at 9:10 PM
@Jeremie,
I do use sagas for ops across bounded contexts, yes. But when I am working in the same bounded context then the aggregate event can be handled in the same thread and do work that may require a service to coordinate, say, between two ARs since they are within the context of a single command. So far this has worked well, but I am open for change :)
Mike, Thursday, November 12, 2009 at 10:11 PM
What test framework are you using (the context-specification bit)? Or is it something hand-rolled?
Graham, Friday, November 13, 2009 at 10:03 AM
Is there's an improvement or some change to be made if the architecture is implemented in Web ?
Thanks before.
Welly Tambunan, Friday, November 13, 2009 at 1:28 PM
@Graham
I use a single class that I got from Greg and I extended it do also be able to do some auto mocking, but I am not 100% sure yet about the auto mocking. The base classes are in the repo.
@Welly TamBunan
Well not really, you would start sending your commands from the Controller (MVC assumed), but if you look at my code you will see that this happens from the Presenters (MVP) so that is basically the same. You might not want to use a bus for the commands, that depends where you want to 'host' your domain.
Mark Nijhof, Friday, November 13, 2009 at 8:24 PM
It's interesting to see how you are discovering the architecture of 30-years old
blackboard systems (http://gbbopen.org/)
Vladimir Sekissov, Friday, December 11, 2009 at 5:31 AM
Hi Mark,
I was trying to understand your sample. I am new to DI.
I could not understand how and where you have added Command to CommandHandler and Event to EventHandler in CastleWindsor. I could not find anything in code where they are registered to StructureMap.
Pl help..
Thanks,
Bkak.
Register commandHandler, Friday, December 25, 2009 at 12:03 PM
To be clear, I like idea of the Event Sourcing. But I am not sure that it applicable for DDD. At least I cannot imagine acceptable implementation. I think your example is overloaded with infrastructure stuff... I blogged about this - http://chaliy.name/blog/2009/12/event_sourcing_and_ddd , but really do not think that this is super useful...
Mike Chaliy, Sunday, December 27, 2009 at 7:40 PM
Hi Mark,
I was wondering if you would be clarifying the impact of eventual consistency on the reporting context where queries over that context are used to make decisions in domain logic? I've read (somewhere and maybe not written by yourself) that these queries which domain logic is dependant upon should be over data in the reporting system and not within the domain itself and thus conforming to the paradigm that the Command-side is only for domain logic and the creation of domain events. This is fine if both sides of the CQRS are in the same thread and transactional context but I'm concerned about the impact of the reporting database being outside this transactional boundary and the impact that may have upon the domain logic making incorrect decisions due to a stale view as input. Your comments please?
I'm also toying with a scenario of how to present the availability of commands to a user via a view(model) considering that quite often the UI Presentation is focused towards presenting only those functions they are allowed to be performed (by the individual user) at that time. I realise that this view will never 100% be correct as the domain can change the split second the view is rendered but this is often preferable to the business stakeholders over presenting every possible option. I'll paint a specific scenario firt.
If I have a command called CustomerChangedAddressCommand I may only wish to present the availability of this command to a user who has a specific AD role (regular role authorisation check) and if the user is a member of a specific Region(UL) where that Region is in a list of list of Regions associated with the individual Customer for management purposes, i.e. Customer is associated with Region in the context of a Command. So, the Guard would determine which (if any) Regions the submitting User is a member of and then ascertain if any of those Regions are associated with the Customer in the context of the sent Command.
The above are Guards I would naturally provide at the start of the CustomerChangedAddressCommand prior to any logic executing but I'd like to understand the following if I may:
a. If Views are to only come from the view (reporting) database this would imply that ViewModel properties such as a list of available commands would be served by this database? Or put another way, how do I determine the value of the CanExecuteCustomerChangedAddressCommand property to give to the viewmodel without availability of domain logic?
b. A denormalised view of Customer in regard to all users in the context of the commands that can be exercised upon them would mean huge amounts of data in this database and potentially lots of record changes when for example a user is removed from a region. Is it necessary to denormalise here or am I taking the denormalisation word out of context here?
c. Maybe this type of feature just isn't compatible with the architecture?
I'll leave it there for now but your comments would be appreciated as they are recurring scenarios for me in several projects.
I really thank you for providing your example of the architecture.
Mark
Mark Phillips, Thursday, December 31, 2009 at 2:15 AM
Hi Mark
I'm in love with your sample application. No honestly.. ..i can't belive how nicely you bring together all those concepts, for an example of both CQRS and event sourcing, that just feels right!
I haven't spend too long with it, but to me it still looks pretty flawless. You probably see the places where improvements could be made.
One thing though i am realy struggeling with is how changes are made to the code, while retaining compatibility with previous events.
Say after a couple of month of running your example in production, version 2.0 is developed and a discision to split ClientName into two seperate properties for FirstName and LastName is made. For instance ClientNameChangedEvent might now have two properties instead of one and so is not compatible with previously events.
Do you have any thoughts on how you would go about handling this?
Olav Rask, Wednesday, February 24, 2010 at 8:38 AM
I would like to read an answer of Mark Phillips' message on 31 december. There are interesting points to discuss.
Jerome , Friday, February 26, 2010 at 10:17 PM
@Mark Philips
You set up an interesting scenario, where the availability/visibility of a command is dependent on some state of the domain, which needs to be interpreted by some domain logic. I would say a valid question.
Your concern is in the fact that the visibility of this command would have to be determined at the reporting side, where this domain logic is not available.
Two things come to mind as directions to find a solution for this:
1. Add (possilbly denormalized) this information in the reporting model. Mind you, it will have to be part of information sent through the domain events as well then.
2. If the logic needed to determine which commands can be executed is complex and dependent on a lot of different factors, the designer of such a model would have to ask himself the question whether users will still be able to understand all of this. Doesn't it 'really' depend on some property of the data (Address in this case) which seems to be missing from the model?
Hope this helps.
Rick van der Arend, Saturday, February 27, 2010 at 12:25 PM
@Olav
Greg actually handles this scenario in his 2-day training quite well.
As said, the events are read-only and not to be disturbed. So they will be kept in their current version. Unless you do some full scale migration, but we are talking normal operation here.
He proposes three things:
- Add a version number to your event name. So ClientNameChangedEvent_v2.
- Work with the current version of the event in your Aggregates (this would be v2 now)
- Make converters like Converter<ClientNameChangedEvent, ClientNameChangedEvent_v2)
There are of course multiple ways of doing this. The important thing will be that, as in all public interfaces (which the events are), the versioning will have to be explicit. It's best to be explicit about it, as the differences can be subtle, so the effects of not noticing them can have an effect that's only picked up long after they have been introduced.
Rick van der Arend, Saturday, February 27, 2010 at 12:56 PM
Thanks for the great example Mark!
I think the implementation of the various IsWhatever domain methods you have implemented should not throw exceptions as they currently do. Instead the caller of the methods should receive a boolean return value and act accordingly. Current implementation has the following problems:
1. Has an assumption within the method about the context in which it is called.
2. Throws an exception in a non exceptional scenario- the throwing operation can fulfill it's stated purpose.
3. Violates CQS.
This will become apparent as more functionality is added to the system which may not require exceptions to be thrown when these methods return a negative answer.
Guy Kedem, Saturday, February 27, 2010 at 8:09 PM
Hi Guy,
I don't agree with your assessment about the exceptions, they are exceptions, because this behavior should not be called from the client in the first place. If it does get called then it is an exception. If on the other hand it is something that should be handled gracefully then you don't throw an exception, you just don't do it, or set some state somewhere. You just don't return stuff from the commands only Ok/Nok which is basically what an exception is.
About the CQS, I don't see that either, well if I would return stuff like a boolean then I would be violating it, but all commands are just that and they do something on the domain, an exception is not a result of a query, they are exceptions. If you need some information whether or not something went ok, then you need to ask the reporting store.
I could agree that my client application is not smart enought to not allow stuff to be called if it is obviously not allowed, like withdrawing money without a balance.
Hope that helps,
-Mark
P.s. my main blog has moved to ElegantCode.com and I don't actually get properly notified of comments left here :(
Mark Nijhof, Saturday, February 27, 2010 at 8:44 PM
Mark, when implementing methods it is bad to assume the action that will be taken based on their outcome. If you were to make a small change to this app, say allowing your client to overdraw his account, you might ask IsBalanceHighEnough() and see that an exception is no longer in order. IsBalanceHighEnough should do what it says, answer a yes or no question, if you still think that an exception should be thrown (which it shouldn't, .net design guidelines stipulate that "Exceptions should only be thrown in response to a runtime error. Exceptions should never be used to direct the normal flow of execution in a program.") at least agree that it is not well named.
Guy.
Guy Kedem, Saturday, February 27, 2010 at 10:28 PM
An exception should be thrown when something exceptional happens, something that should not be able to happen, like executing something on a closed account. I don't agree with the .Net definition that it should only happen on runtime errors.
Also Yes you are correct that overdrawing should not result in an exception (I guess you are seeing the example app to much as a real scenario). But the result from a command should not communicate something back other then Ok or an exception. I.e. the command was successfully executed or not. If you need more feedback then you should ask the reporting store, else you are basically reading from your domain again, something that this pattern goes in great lengths to prevent you from doing.
Hope this helps,
-Mark
Mark Nijhof, Saturday, February 27, 2010 at 10:48 PM
Try to execute a command that is not logicly acceptable IS a runtime error. an exception should be thrown, you are absolutely right. Just not from the IsWhatever method but from the method that calls it.
Good Luck on elegant code!
Guy Kedem, Wednesday, March 03, 2010 at 12:53 PM
Hi there,
Situation :
1. We have a database with more than 500 tables, divided by domain (Agencies, Vehicules, etc)
2. We use CQRS/ Query for querying or Reporting Model
Question : If I need a report involving vehicule BUT my customer asked me for adding a column containing Agency information.
Do I :
1. Apply directly Querying methodology of CQRS and synchronize a table containing the aggregated columns ?
2. Use aggregation of service to compose response ?
Futhermore, If I need an method to give the number of vehicule, is it a Query method, working in the same way as other query method ?
Jerome , Tuesday, March 23, 2010 at 7:56 AM
Hello there,
I have a question here. Is it OK in External event handler to perform query operation in reporting database before you do write stuff ? For example event has customer GUID and I do query database for some other information about customer and then issue command with that information let's say to some other sub-system (bounded context)
Tomas Bartkus, Monday, March 29, 2010 at 8:15 PM
Recent blog posts
- Follow me @ Elegant Code
- CQRS à la Greg Young
- CQRS à la Greg Young example code
- My Kindle DX
- My book: Are You Better Than Yesterday?
- Running with Scissors
- Applying Domain-Driven Design and Patterns
- Hey Developer, YAGNI I tell you
- Hey Developer, the product you create is your code
- NDC videos are published
Excellent post, it's great to see the whole system all mapped out. I remember coming across Greg's stuff about 18 months ago and having to put all of the little bits and pieces together from his presentations, blog posts, and DDD forum messages. I'm glad to see some good information on this architectural style starting to get out there more.
Jonathan Oliver, Thursday, November 12, 2009 at 4:52 AM