Latest news and articles about DDD, CQRS, Event Sourcing and Software Architecture in general, aggregated daily and delivered weekly to your feed (RSS) reader. Subscribe here!

Week 21, year 2019

  • Messaging Patterns: Throttling - Throttling Only keep one event per time unit from a high frequency stream. Problem A stream of Ephemeral Events is too much to handle for a consumer. Solution An intermediary consumer is placed in front of the original consumer. It drops all events, except once per time unit, where it passes the event to the original consumer. Example This pattern is very common in user interfaces. An input device, such as a mouse, emits it’s position at 500 Hz. [Mathias Verraes]
  • Messaging Patterns: Ephemeral Events - Ephemeral Events An event’s lifetime lasts until the next event. Problem Some producers, such as sensors, emit realtime or near-realtime measurements, expressed as events. A new measurement makes the previous measurement obsolete. These events can be sent at regular or unpredictable intervals, but they are often high frequency. Consumers aren’t capable of keeping up with all events, or aren’t interested in processing all of them. Solution Mark the events as being Ephemeral Events. [Mathias Verraes]
  • Messaging Patterns: Change Detection Events - Change Detection Events Listen to a stream of events and produce a new event when a value changes. Problem A consumer is interested in an event stream, but the consumer only wants to know when a particular value changes, and doesn’t care about the events where that value didn’t change. Optionally, the consumer only cares when the value changes more than a given interval. Solution A second intermediary consumer is placed in front of the original consumer. It acts as a filter, emitting Change Detection Events when the observed value is different from the previous event. It may also ignore changes that are too small for the original consumer. [Mathias Verraes]
  • DDD and Messaging Architectures - My aim is to identify, name, and document patterns, that I’ve used or encountered in my consulting practice. All patterns are anti-patterns when used in the wrong context, so I try to add heuristics, trade-offs, and caveats. You can help: tell me your experiences, point me to other people’s writings on patterns, distill your own heuristics, … Meta Eventsourcing: State from Events or Events as State? Patterns Are Not Defined by Their Implementation Patterns for Decoupling in Distributed Systems Domain Queries Summary Event Completeness Guarantee Passage of Time Event Fat Event Explicit Public Events Segregated Event Layers Eventsourcing Patterns Forgettable Payloads Crypto-Shredding Decision Tracking Migration Events in a Ghost Context Multi-temporal Events General Messaging Patterns Ephemeral Events Throttling Change Detection Events Natural Language Message Names Testing EventSourcing Testing Patterns Note: I teach workshops about DDD for Messaging Architectures. [Mathias Verraes]
Permalink | From 20 May 2019 to 26 May 2019 | Last updated on: Sun, 28 May 2023 22:06:33 GMT