Event Sourcing. Capture all changes to an application state as a sequence of events.
We can query an application's state to find out the current state of the world, and this answers many questions. However there are times when we don't just want to see where we are, we also want to know how we got there. Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes. How it Works The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself. Let's consider a simple example to do with shipping notifications. Figure 1: A simple interface for tracking shipping movements.
Reversing Events. CQRS. Domain driven design · application architecture · API design tags: CQRS stands for Command Query Responsibility Segregation.
It's a pattern that I first heard described by Greg Young. At its heart is the notion that you can use a different model to update information than the model you use to read information. For some situations, this separation can be valuable, but beware that for most systems CQRS adds risky complexity. The mainstream approach people use for interacting with an information system is to treat it as a CRUD datastore. As our needs become more sophisticated we steadily move away from that model. As this occurs we begin to see multiple representations of information. This structure of multiple layers of representation can get quite complicated, but when people do this they still resolve it down to a single conceptual representation which acts as a conceptual integration point between all the presentations.
There's room for considerable variation here. When to use it. EagerReadDerivation. Domain driven design · application architecture tags: One of the interesting talks I attended at QCon San Francisco, was one given by Greg Young about a particular architecture he'd used on a recent system.
Greg is a big fan of Domain Driven Design, in this case it needs to be used with a system that has to process a high transaction rate and provide data to lots of users. There were a number of things I found interesting about his design, particularly his use of Event Sourcing, but for this post I want to dwell on just one aspect - what I'll call Eager Read Derivation. When we use a Domain Model, we use it because it contains complicated domain logic. Validations: checks that input makes sense and objects are properly suited for further actions. consequences: initiating some action that will change the state of the world derivations: figuring out some information based on information we already have These kinds of domain logic apply differently to updates than to reads.
11 Stratégies. This is a guest posting by Marty Abbott and Michael Fisher, authors of The Art of Scalability.
I'm still reading their book and will have an interview with them a little later. If 2010 is the year that you’ve decided to kickoff your startup or if you’ve already got something off the ground and are expecting double or triple digit growth, this list is for you. We all want the attention of users to achieve viral growth but as many can attest, too much attention can bring a startup to its knees. If you’ve used Twitter for any amount of time you’re sure to have seen the “Fail Whale”, which is so often seen that it has its own fan club.
Take a look at the graph below from Compete.com showing Twitter’s unique visitors. What should you do if you want your startup to scale with double and triple digit growth? 1) Scale Out – Not Up This one shouldn’t come as a surprise to anyone. 2) Use Databases Appropriately 3) Soar Through the Clouds 4) Goldfish not Thoroughbreds 5) Simplify, Simplify, Simplify.