archie · May 20, 2019 07:36 · Apr 8, 2014 · Apr 8, 2014
diff --git a/ddd_cqrs_es.md b/ddd_cqrs_es.md
@@ -30,7 +30,11 @@ In preparation for a new gig I'm reading up on the terms Domain-Driven Design, C
 * Aggregates are composed of smaller events. E.g., a purchase order contains line items
 * I'd read Werner Vogel's [eventually consistent](http://www.allthingsdistributed.com/2008/12/eventually_consistent.html) post before, but stumbled upon it again and reread it. It's good. 
 * Examples in C# on [CQRS and Event sourcing](http://msdn.microsoft.com/en-us/library/jj591577.aspx)
+* [Akka and event sourcing](http://www.slideshare.net/ktoso/akka-persistence-event-sourcing-in-30-minutes) - stumbled across a tweet from [scalarconf](http://scalar-conf.com/) and I spotted this presentation by [Konrad Malawski](https://twitter.com/ktosopl). 
+* Description of [EventStore's architecture](https://github.com/eventstore/eventstore/wiki/Architectural-Overview)
+* "If you sat down with them [a customer], explaining the long-term value of having an archive of all actions in the system, and they said OK, build this into the system from the beginning, that would be fine." - Dahan
+* Food for future thoughts: [Reactive Design Patterns](http://manning.com/kuhn/RDP_meap_CH01.pdf), [Reactive Manifesto](http://www.reactivemanifesto.org/), [SEDA](http://www.eecs.harvard.edu/~mdw/proj/seda/), and [Retrospective on SEDA](http://matt-welsh.blogspot.se/2010/07/retrospective-on-seda.html). 
 
 <small><a name="footnote1">[1]</a> This may also mean that industry have come up with a marketable name for something researchers have been thinking about for a long time already.</small> 
 
-<small><a name="footnote2">[2]</a>I got kind of frustrated/annoyed with this claim in Dahan's article: "How fast they get processed is a question of Service-Level Agreement (SLA) and not architecturally significant." To me it seems an SLA, determining much of a systems quality attributes, is definitely something architecturally significant. Maybe I just don't get what he's trying to say?</small>
+<small><a name="footnote2">[2]</a> I got kind of frustrated/annoyed with this claim in Dahan's article: "How fast they get processed is a question of Service-Level Agreement (SLA) and not architecturally significant." To me it seems an SLA, determining much of a systems quality attributes, is definitely something architecturally significant. Maybe I just don't get what he's trying to say?</small>
diff --git a/ddd_cqrs_es.md b/ddd_cqrs_es.md
@@ -0,0 +1,36 @@
+# DDD, CQRS and Event Sourcing
+
+In preparation for a new gig I'm reading up on the terms Domain-Driven Design, Command-Query Responsibility Segregation, and Event Sourcing. Here are a list of useful texts and talks that I've discovered so far. If anything is missing please leave a comment. 
+
+## DDD
+
+* [Eric Evans: What is a model?](http://dddcommunity.org/library/evans_2009_2/) - "A model is not a UML diagram nor a certain layer of the software. [...]. It is a system of abstractions, it describes selected aspects of a domain, and can be used to solve problems related to that domain."
+* [Eric Evans: What I've learned since the book](http://dddcommunity.org/library/evans_2009_1/) - slightly longer talk on Eric's findings since he co-authored _the_ book on DDD. 
+* [Eric Evans: Domain-Driven Design](http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215) - As far as I can tell, _the_ book on DDD. Haven't read it though. 
+
+## CQRS
+
+* [Command-Query Separation](http://martinfowler.com/bliki/CommandQuerySeparation.html) - although first defined in a book by Bertrand Meyer, Fowler makes a great job explaining CQS, the predecessor (sort of) to CQRS. 
+* [Command-Query Responsibility Segregation](http://martinfowler.com/bliki/CQRS.html) - the term is coined by Greg Young (more links below), but again described well by Fowler. Builds on CQS. "At its heart is a simple notion that you can use a different model to update information than the model you use to read information." Moreover, "CQRS allows you to separate the load from reads and writes allowing you to scale each independently" is something I have studied previously, but don't remember using this term for it before. Neat! [1](#footnote1) 
+* [Udi Dahan: Clarified CQRS](http://www.udidahan.com/2009/12/09/clarified-cqrs/) - Command-Query Responsibility Segregation "explained". Two significant components Dahan addresses that others have left out are _collaboration_ and _staleness_. [2](#footnote2)
+* [Greg Young's summary on CQRS](http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/) - The "invetor's" own summary of the CQRS pattern. Perhaps the most straightforward explanation I've seen so far, but flies over some important aspects of what the pattern means for the data model in my opinion.   
+* [CQRS pattern explained by MSDN](http://msdn.microsoft.com/en-us/library/jj591573.aspx) - Good and detailed description of the pattern. Also includes a helpful section on when not to use it (and it has pictures). 
+
+## Event Sourcing
+
+* [Fowler on Event Sourcing](http://martinfowler.com/eaaDev/EventSourcing.html) - The gist in one line: "Capture all changes to an application state as a sequence of events." Two notions I find particularly interesting are _Temporal Query_ and _Event replay_. The post also includes a good list on some challenges with Event Sourcing. 
+* [Event Sourcing explained by MSDN](http://msdn.microsoft.com/en-us/library/jj591559.aspx) - The section on Performance, scalability and consistency is useful. 
+* [EventStore](https://github.com/eventstore/eventstore/wiki/Event-Sourcing-Basics) - the basics of storing events rather than objects. "[...] data is not persisted in a structure but as a series of transactions."
+* [A deep look into the Event Store](http://vimeo.com/53153270) - talk by Greg Young from the Oredev conference, Nov 8, 2012.
+
+## Additional notes
+
+* "Focus relentlessly on the core domain" - Evans
+* "CQRS is not a top-level architecture. CQRS is something that happens at a much lower level, where your top level architecture is probably going to look more like SOA and EDA." - Young
+* Aggregates are composed of smaller events. E.g., a purchase order contains line items
+* I'd read Werner Vogel's [eventually consistent](http://www.allthingsdistributed.com/2008/12/eventually_consistent.html) post before, but stumbled upon it again and reread it. It's good. 
+* Examples in C# on [CQRS and Event sourcing](http://msdn.microsoft.com/en-us/library/jj591577.aspx)
+
+<small><a name="footnote1">[1]</a> This may also mean that industry have come up with a marketable name for something researchers have been thinking about for a long time already.</small> 
+
+<small><a name="footnote2">[2]</a>I got kind of frustrated/annoyed with this claim in Dahan's article: "How fast they get processed is a question of Service-Level Agreement (SLA) and not architecturally significant." To me it seems an SLA, determining much of a systems quality attributes, is definitely something architecturally significant. Maybe I just don't get what he's trying to say?</small>
No results found