My views don't differ at all. In fact they are further enforced when using CQRS. If a Command is issued, and that command cannot complete - that is an exception.
Code: Select all
try {
$someObject->doSomething();
} catch (CouldNotDoSomethingException $e) {
// etc.
}
I tell an object to do something (give it a command), I expect it to do it. If it cannot complete the command, that is a deviation from the expected path/flow, and thus an exception.
That's if it's a CQRS implementation.. but as the latter part of my post points out, if it is not then returning (not throwing) the event is fine.
Code: Select all
$someEvent = $someObject->doSomethingAndReturnTheEvent();
$eventStore->Store($someEvent);
Trigger an event/command to record the action of the user link click (and the validate security etc) - but when fetching the result, do it in the quickest way. The command is to increase the counter (or whatever) but the read operation is still a separate operation.
Code: Select all
$command = new UserClickedOnFooLink($user);
$commandHandler->Handle($command);
echo $queryHandler->GetViewForFooLinkForUser($user);
Anyway, this is more about CQRS than it is Event Sourcing. Event Sourcing is simply using an Event Store to persist your domain state as a sequence of changes, instead of a set of values that you update (i.e. 'current state').
Here is another link by Greg Young (the guy in the video I posted earlier) titled "Why use Event Sourcing?"
http://codebetter.com/blogs/gregyoung/a ... rcing.aspx which will (hopefully) make things clearer.