That appears that I almost turned all the presentation of Greg into the notes file sentence by sentence. You must watch it to appreciate the wisdom of his and what CQRS and ES bring to the table.
- You can use CQRS without Event Sourcing, but with Event Sourcing you must use CQRS
- compare time periods to time periods deterministically
- audit log and be able to prove its correctness
- your account balance is the first level derivative off of the facts on your account
- current state is transient = it’s the first level derivative
- not about memory
- I can delete and rebuilt it
- events = facts
- 8:51 event sourcing is all about the storing facts and at any time you’ve state structural models that are first level derivatives off of your facts and they’re transient
- 10:28 Structure changes more often than behaviour
- 10:32 Your use cases of a system tend to be reasonably stable over a long period of time.
- 11:14 Accountants do not do this unless they worked for Enron
- 11:21 You do not erase something in the middle of your ledger. This is highly illegal.
- 11:26 If you took in a class in accounting you've probably been told that accountants don’t use pencils - they use pens. The same can be said about event sourcing.
- 11:36 When we talk about event sourcing you can never ever update an event. And you can never delete an event.
- 12:17 If I can take all of your data and I can put it on microSD you don’t have a big data
- 12:23 if I can put all of your data on microSD you do not need to worry ever about deleting any data (providing your system has been running for more than over a year)
- 12:55 If you’re going to be faster than Moore’s law then you don’t have to worry about the amount of data you have. Your data will just continually get cheaper and cheaper and cheaper for you to store.
- 13:38 For most of you do not worry about deleting events.
- 15:06 Just like in a ledger you’re not allowed to ever go back and update something. You can only add new things. You can do corrections.
- 16:24 In most places I find it’s the business to drive the use of event sourcing not the technology reasons
- 16:32 And the reason why people are using it is that it's the only model that does not lose information
- 17:40 How did you make the decision to destroy your data? You personally didn't feel it’s valuable? Or maybe you didn’t think about it?
- 17:50 data is massively valuable
- 35:29 Rolling snapshots = snapshot the state as it was at the point in time for the projection. With this, you can replay from a snapshot forward.
- 35:51 Event sourcing is functional data storage mechanism
- 36:02 Current state is a left fold of previous behaviours
- 36:10 A snapshot is a memoization of your left fold
- Events are immutable
- 36:59 You can never edit a projection
- 39:58 You have a choice. You can either wear a fireman hat or you can wear a cowboy hat. It’s a good strategy.
- 40:45 There are a lot of domains that are naturally event sourced.
- 41:14 And we wonder why docktors have hard times understanding CRUD-based systems. When they’re natural mental model is the appending of facts.
- 42:00 There are vast number of business problems that are naturally event sourced.
- 42:17 Overall, event sourcing is a beautiful transactional model - it’s append-only, immutable.
- 43:37 Append-only, immutable logs are absolutely brilliant for a lot of things
- 43:49 So when I event sourced my system, how do I answer the question I wanna see all the users with the first name ‘Greg’. Do I replay the entire event log for every user in the system to figure out at the end of it if the first name is Greg? That’s gonna be spectacular. Basically imagine that every single query you do has to be a table scan of every event your system has ever done. That’d be AWESOME! And this is when we come to CQRS.
- 44:36 CQRS basically says that you don’t want one system - reading and writing are different and you should make different decisions for reads and for writes. CQRS at its core is probably the ??? pattern ever imagined.
- 44:54 CQRS actually comes from CQS - Command and Query Separation which is from Bertrand Meyer
- http://en.wikipedia.org/wiki/Command%E2%80%93query_separation
- 45:05 Object-oriented software construction I would recommend getting the 2nd edition
- I warn you as the book seems to be event sourced - it looks like it’s append-only and he just keeps adding to it on every edition.
- 45:30 What CQS states is very simple - there are two types of methods: the first type has a void return type - it’s called a command. It’s allowed to mutate state. It’s not a pure function. The second type has a non-void return type - it is not allowed to mutate state - it’s called a query.
- 46:31 It makes it much easier to reason about your code. And the reason it was so important to do this inside Eiffel - which is the language he writes - is because it has something called contracts. And contracts are normally written on top of pure functions. And what happens if I called your contract twice? Should that somehow alter your behaviour? That’d be weird. What if I realized I don’t need call your contract and now you worked differently because I didn’t call your contract? That’s weird.
- 47:02 Martin Fowler wrote that CQS is not a principle. It’s instead a rather reasonable suggestion.
- 47:13 If you know Martin you can imagine him saying that in his British voice.
- 47:56 CQS becomes much more important when we start talking about things in a distributed system. And the reason it becomes so much more important is because we start talking about things like idempotency. While queries are going to be naturally idempotent, commands are not going to be naturally idempotent.
- 48:16 CQRS goes one step further than this.
- 48:19 and btw how many of you have seen something in CQRS that said underneath it “Did you mean CARS?" And this is because back in 2007 or so if you typed CQRS in Google it’d say “Did you mean CARS?”
- 48:44 CQRS basically says we’re going to have two objects now - we’re going to take the one object to fill in with commands and queries and we do two objects out of it - one for all the commands and one for all the queries. And actually they called it a pattern. How weird is that? It’s such a simple concept. But it’s an enabling pattern.
- 49:12 Queries tend to have a different perception of your data. Almost always a query is focused on a screen. And what the screen looks like? Does a screen have anything at all to do with managing your transactional invariants? Probably not. If they do have similarities it’s accidental. There’s no causative relationship between this. Queries are screen-related because you want to do one call across the wire to come back because you're perceived as being faster then.
- 50:00 In most systems, queries are what you need to scale. Most systems I looked at do an order of 1 to 2 orders of magnitude more queries than they do processing of commands. I’ve seen them all the way up to 4-5 orders of magnitude.
- 51:08 queries are generally what we need to scale.
- 51:10 Most people what they’re doing today they’re building up a domain model on top of a database and when it comes to scaling they talk about scaling everything. We don’t need to do that. We can talk how to scale our queries and not talking about scaling our commands.
- 51:27 There’s really an interesting property about queries that makes them specially easy to scale. Commands are hard to scale. Queries are very easy to scale because almost all queries can operate with relaxed consistency. Queries can be eventually consistent. When it comes to process commands I really need my current state in order to do this reliably and it gets very complex if I do it in an eventually consistent way for validation. Queries can almost always be eventually consistent.
- 52:16 Guess what, you’re already eventually consistent. You just don’t know it.
- 52:43 So you’re already eventually consistent. You're just not taking advantage out of it.
- 52:53 Queries become super, super easy to scale.
- 53:05 And BTW, I do this talk a lot in Europe and I always feel bad for English as the second language people because the write side is on the left and very often they get confused.
- 53:19 On one side we’ve got our domain objects with application services and normal DDD-style stuff. On the other side we’ve just got the thin read layer that goes directly to database with no ORM or anything crazy like that and just returns DTOs quering the database.
- 54:00 (With Read/Query layer) you’re linearly scalable now. You can geographically distribute them. And it’s almost always queries that are the interesting part of this.
- 54:12 To be fair, if anyone here happens to be working in finance, yes, I know, you get many many more writes than reads. And there are systems like this, but there are far fewer
- 55:38 When we talk about this, it’s very uncommon that you have a single read model. Normally you have multiple read models for doing different kinds of queries.
- For UI - document database as it aligns well to how much screen looks like.
- OLAP querying
- Full-text indexing with Lucene
- All are projections
- You can have as many projections as you want in Event Sourced system.
- 57:12 Remember that that’s not one read model you’d have - most systems require two/three/four different read models to actually work well.
- 57:20 And there’s a massive accidental complexity to try to use a single read model.
- 57:29 State transitions are important concepts of our domains. The result of an operation - what that means - is an important concept - it’s a fact.
- 57:41 Overall, getters and setters in domain models are code smell. If you start seeing lots of them, start thinking of what you’re doing.
- 57:55 You cannot under any circumstances have a single model that does everything for you and does it well. it doesn’t exist. There’re different types of models and different models do good at different things.
- On the slide: A single model cannot be appropriate for reporting, searching, and transactional behaviours
- 58:34 Just like event sourcing doesn’t work well for everything. You can’t do query of the current state in a purely event sourced system. You need some piece of transient state to be able to query with it. It will help you and save you a lot of accidental complexity.
- 59:43 My aggregates are fully consistent.
- 1:02:45 I would not even consider doing a snapshot until I hit about a thousand or maybe more.