I think the idea of eventual consistency is quite interesting and I can see how taking this approach instead of trying to create the impression that everything the user does is in real time we can make life much easier for ourselves. I’m not sure how this type of idea works when users have the expectation that when they change information on a page that it is updated straight away though. For example on a form I might decide to change my address and I would expect that if I reload the page with my address on that it would now display my new address instead of the old one. If that address was eventually consistent after 5 minutes for example the user might become quite confused and send in another update to try and change their address again. Liz pointed out that with bank transactions it is often explicitly described to users that money transfers are 'pending' so perhaps the expectation that things aren’t done in real time has already been set in some domains. Werner Vogels has a nice article about eventual consistency in distributed systems in which he references a paper by Seth Gilbert and Nancy Lynch which talks about the idea that "of three properties of shared-data systems; data consistency, system availability and tolerance to network partition one can only achieve two at any given time."

Dave pointed out that the idea of 'POST redirect GET' often used when processing web form submissions seems to adhere quite nicely to the idea of Command Query Separation as described in the video. I find it quite interesting that CQS at the method level in our code is usually quite closely adhered too but so often we’ll just bolt on getters onto domain objects so that we can access some data to display on the view. The idea of not doing this and having a write only domain seems very interesting and seemed to make sense in the system that Greg described. It would be interesting to know whether one would follow such an extreme approach at the architecture level if there weren’t such high performance requirements or the need to have all the operations performed on the system available for an audit.

Greg’s idea of state transitions sounds quite similar although perhaps not exactly the same as Eric Evans' 'domain events' which he discussed in last week’s book club. It would be interesting to see what the code to process form submissions by the user would look like with this approach. As Silvio pointed out, the complexity of this code would probably be much higher than in a more typical approach where we might just build our domain objects straight from the data the user entered. Using Greg’s approach we would need to work out which state transitions had actually happened based on the user input which would presumably involve keeping a copy of the previous state of the domain objects in order to work out what had changed. I like the idea of making concepts more explicit though and the idea of keeping all state transitions is something that is built into databases by way of their log by default so it’s not a completely new concept. Pat Helland has a cool post titled 'Accountants don’t use erasers' where he describes it in more detail.