🗞 Stream Recap: CQRS and Actors
Engineering Culture #18—Here's what you missed
Talking Points
“CQRS is the outcome of separating decision making and state management. An aggregate takes care of enforcing and protecting rules, a projector takes care of catering to UI or downstream automation.“
“DDD practicing engineers, especially beginners, are quick to dismiss the value of domain events.“
“Without deeper event architecture experience you are limited to the four patterns that do not use them, making adoption of streaming, event sourcing and CQRS a colossal learning curve.”
“There is a graduation point in every engineer’s learning path where they adopt simpler, event-driven architectures. When stateless, it may come in forms of CQRS or data processing. Stateful, often actors or UI logic.”
“When growing from a state-based (SQL) understanding, it’s easy to confuse projections thinking they are events or event-outcomes. Spot in your database a table that has a log or history pair adjacent to its state. Is the history decorating the state to not lose data or is the state computed as a view from the log? The former is a state-based system with mutable, throw-away logs. The latter is event sourcing.“
“Cloud architects, enterprise architects and software architects differ by the combination of patterns they use and the stack they use it on.”
Recordings
Highlights (AI generated)
Event sourcing provides a more solid representation of actions by ensuring the immutability of past events, leading to better management of user expectations and handling of corrections from the backend server.
📊 CQRS and Actors are key concepts in software architecture, with CQRS relying on domain events and nine tactical patterns, while Actors handle high concurrency and data flows, with automated commands triggered by user actions or timers.
🧠 Understanding software patterns and event modeling is crucial for architects, as actors can improve concurrency-friendly architecture and event sourcing is important for future states and task processing.
🪞 Proper projections in databases should be based on events, event sourcing provides a more solid representation of changes, CQRS involves understanding data, and learning event sourcing is important in complex software architecture. It’s easy to get the terms mixed up.
🔑 Delegating user actions to multiple services and handling event generation and processing is crucial in back-end systems, as developers often overcomplicate systems by not utilizing event-based systems, resulting in unnecessary [middleware] state complexity and a disservice to their team.
🔑 Using commands to event state transition and event-based architectures with different time windows can solve complex communication and performance issues, as demonstrated by Quake's use of client-side prediction and event sourcing for instantaneous weapon feedback.
📊 Engineers should learn event-driven architectures and event sourcing, including different variants and front end integration patterns
🎭 Actors in CQRS systems allow for high-speed, low-latency, and fault-tolerant applications with stateful requirements, enabling event-driven communication and supervision for handling potential corrections. This comes at the cost of managing the complexity of actor states.