Jean Tessier’s Reviews > Domain-Driven Rails > Status Update

272 - Glancing at Eventide. Repeats some of the patterns seen earlier with rails_event_source. Not clear what event mechanism is used in Eventide.

255 - Failure modes for inter-process notifications. Direct calls (grapeater), external queue (Kafka), and/or internal queue (rails_event_store) for transactionality + external queue for broadcasting. Bunny, a Ruby RabbitMQ Client on GitHub.

250 - The author calls ancillary work "side-effects". Functional programming drills into us to avoid side effects, so this double meaning is a little unfortunate.

240 - Automatic failover when error rates exceed threshold. Splitting up complex UIs. The author shows their inexperience, which hurts their credibility. The part on splitting up UIs has nothing to do with anything else in the book!

231 - Separating module using a gem structure (also references Shagemann). Has tips for autoreloading and putting the specs alongside the code in the module structure.

226 - Modularization using gems or Rails engines. Mentions CBRA by Shagemann. Naive opinion that you can easily migrate between engines, microservices, and serverless.

223 - CQRS creates two representations of a piece of data instead of just one. One is optimized for writes and the other is optimized for reads. Infrastructure (the event stream) keeps them (eventually) in sync. Mentions a 2010 post by Greg Young that I cannot find.

The author bailed out on trying to cover versioning of events over the lifetime of a stream.

They use RubyEventStore::Client#append with an explicit expected_version to do optimistic locking. This way, they can change state from "almost published" events but still fail to publish them in case of a collision. This is why they need to rehydrate objects each and every time.

I like that they picked an example app with lots of real life complexity but can be simplified enough for the examples without losing the flavor. Author has worked a lot with ticketing apps.