This document discusses implementing event sourcing in .NET. It provides an overview of event sourcing and CQRS, noting that events capture past occurrences that affect the domain. A demo is shown of a sample event sourcing application using NServiceBus for messaging. The document recommends buying rather than building event store and messaging toolkit components, and lists options for each including SQL Server, MongoDB, RavenDB, MSMQ, NEventStore, and NServiceBus.

2. Implementing
Event Sourcing in .NET
Andrea Saltarello
CEO @ managed/designs
andysal@gmail.com
http://twitter.com/andysal74
http://slideshare.net/andysal

3. Who I am
1. CEO @ Managed Designs, striving to discover the perfect
«sustainable software development process»
• Customer has to be satisfied and pay
• Supplier has to have a reasonable markup
• Team members should be satisfied with their work
2. Founder and leader of UGIdotNET (first Italian .NET User
Group): I need to share experiences in a peer to peer way
3. (Co)Author (together with Dino) of .NET: Architecting
Applications for the Enterprise, by Microsoft Press
4. Basically, a software developer 

4. CQRS recap
Query Command

5. DEMO
CQRS recap

6. It really became clear to me in the last couple of years
that we need a new building block and that is the
Domain Event.
[Eric Evans]
An event is something that has happened in the past.
[Greg Young]
A domain event … captures the memory of something
interesting which affects the domain
[Martin Fowler]

7. Why events?
«Undo principle»: Instead of focusing on a system’s last
known state, we could note down every occurring
event: this way, we would be able build the state the
system was in at any point in time
To cut a long story short: we end up recording an event
stream
JobOrderCreated InvoiceIssuedJobOrderExtended JobOrderClosed

8. Event Stream vs. «My application»
Still, my users are more interested in knowing a
job order’s balance or whether an invoice has
been paid.
Ways to achieve that:
• Rebuilding the state traversing the whole
event stream (slow, but snapshots can help)
• CQRS to the rescue: let’s have a database
dedicated to store the last known state and
have it read by the read model

9. CQRS/ES in a nutshell
1. Application sends a command to the system
2. Command execution alters the system’s state and
raises events to state success/failure
3. Events are notified to interested subscribers, such
as:
• Workflow managers (a.k.a. «Sagas») which can
execute more commands
• Denormalizers, which will update the read
model
Note: command/event dispatch will usually be
managed by a Mediator («bus»)

10. Read
Model
Application
Layer
Domain
layer
Event
store
QUERY
COMMAND
Bus
EVENT Handler
Handler
Handler
Snapshot
DB
CQRS/ES at a glance

11. DEMO
Merp

12. On a technology side…
Looking for a bus and an event store: build or buy?
• Event Store:
–SQLWhatever
–MongoDB
–RavenDB
• Bus:
–NEventStore
–NServiceBus
My advice? Buy
#donoteverthinkaboutmakingyourowntoolkit

13. The “Buy” Side of the Force
SQLWhatever MongoDB RavenDB
• Everyone’s skill
• Every tool you can
need does exist
• Both On-Premise
& cloud
• Free
• Runs on both
Linux and
Windows
• Both On-Premise
& cloud
• Schemaless
• LINQ support
• TX+DTC support
• Schemaless
• Both On-Premise
& cloud
MSMQ NEventStore NServiceBus
• ROTFL • Free
• FOSS
• DDD/CQRS/ES full
stack
• Advances config
options
• Advanced
notifications
features

14. DEMO
NServiceBus

15. Bibliography
[DDD] Domain Driven Design, Eric Evans , Addison-Wesley
What I've learned about DDD since the book, Eric Evans, InfoQ
[NAAE] Microsoft .NET: Architecting Applications for the
Enterprise (2° ed.), Andrea Saltarello & Dino Esposito,
Microsoft Press
[MERP] Merp, https://naa4e.codeplex.com/