Status Updates From Domain-Driven Rails

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.

215 - A long example using EventStoreDB and reading back events through its paged REST interface over HTTP. It supports projections so it can materialize views based on the event stream(s).

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.

Still struggling with changing state before or after publishing effects. I like the way I did it with Kafka where a commands only published events and the state only changed in response to published events from the stream.

185 - Testing can either use events to setup fixtures, it call" commands" directly. You check the expected state and "unpublished events" in one set of tests. You check that events are being published in a separate set of tests.

174 - Their version of event sourcing rehydrates objects of every load(), instead of keeping them in memory.

On page 155, the author discusses how he liked the diagrams in some of the other publications he references. And yet, he has very few in this book. The code samples are nice and short, but a good diagram can do wonders to establish the context.

Process managers are like Saga with orchestrator. The bit about testing permutations using Ruby's #permutation and #repeated_permutation was a really nice touch. According to some, process manager coordinates an action across bounded domains, whereas saga is more for long duration processes. There is a process manager in Enterprise Integration Patterns.

CQS: queries are immutable and return values, commands are mutations and return nil. Too inconvenient for many libraries (e.g., iterators). Reminds me of GraphQL. CQRS: separate stores for reads and writes. Read stores are denormalized, rehydratable. Replaces multi-table queries. Write side preserves biz rules. Read side cannot reject a change; it cannot decide. (p. 137)

Using events instead of AR callbacks. Difficulties in keeping things in sync in the face of tx rollbacks. Just like at Gusto! "Update other Aggregates using eventual consistency" (p.124) Skittish about using microservices out the gate. Example uses rails_event_store.

Domain Events record things that have happened, including failures. They can have multiple handlers and these can be asynchronous. A single action (i.e., command) can lead to multiple domain events. An event can be part of multiple streams, so we can group them according to different dimensions (in week X, about record Y, of type Z).

https://rubygems.org/gems/arkency-com... has 800K downloads.

https://github.com/arkency/command_bus has 48 stars.

Command Bus is a synchronous registry of handlers for different Command objects. Commands group together a bunch of related params and can use ActiveModel to do simple validation. There is at most one handler per command, so we can have a clear success/failure indication. If the handler is asynchronous, then "success" means "it was scheduled" and the real success status has to come from somewhere else, somehow.

Application services orchestrate logic in the application, moving data around and coordinating side-effects. Commands are useful to group pieces of data together. Domain services implement domain-specific logic.

Aggregates are groups that change together and are persisted together. If the group is too large, it can create contention in the DB with large and/or long transactions. If the group is too small, you need to rely more on eventual consistency and undoing something is more involved. Always operate on the aggregate through its root, to validate rules. Aggregates refer to other aggregates by ID only, no Rails assoc.

Bounded contexts vs domain models. Value objects vs entities. Rails makes it very easy to build a big ball of mud. ActiveRecord exposes the details of the database mapping to everyone, making it difficult to refactor unless you have comprehensive knowledge of the application.