Chapter 17. State management and persistence patterns

 

The previous chapter introduced the concepts of message rate, load, and time; previously, we had only considered the timeless relationship between different components. This chapter adds another orthogonal dimension to complete the picture: it is the purpose of almost all components to maintain state, and we have not yet discussed how this should be done. The patterns presented are closely related to each other and form a cohesive unit:

  • The Domain Object pattern decouples business logic from communication machinery.
  • The Sharding pattern allows you to store any number of domain objects on an elastic cluster.
  • The Event-Sourcing pattern unifies change notifications and persistence by declaring the event log to be the sole source of truth.
  • The Event Stream pattern uses this source of truth to derive and disseminate information.

This chapter can only serve as a basic introduction to these patterns. We hope it inspires you to delve into the rich literature and online resources on domain-driven design, event sourcing, and command-query responsibility separation (see the footnotes throughout the chapter for pointers).

17.1. The Domain Object pattern

Separate the business domain logic from communication and state management.

17.2. The Sharding pattern

17.3. The Event-Sourcing pattern

17.4. The Event Stream pattern

17.5. Summary