Stores

Comby provides a flexible and extensible architecture for managing different types of stores, including the EventStore, CommandStore, DataStore, and CacheStore.

All of these are defined as interfaces, allowing developers to implement their own custom storage solutions tailored to specific requirements. Comby also includes several ready-made implementations to simplify development. For example, in-memory implementations are available for all stores, providing a lightweight option for testing and prototyping.

INFO

Although the stores are represented within the facade here, this is not strictly necessary. Depending on the use case, a store can be created independently, such as for testing purposes. In production environments, however, the store is typically accessed through the facade. By default, if no specific configuration is provided, the in-memory variant is used.

EventStore

The EventStore handles the storage of Events in an event-driven architecture. It serves as the central source for changes to aggregates and enables event sourcing. In addition to an in-memory implementation, Comby provides SQLite and PostgreSQL-based solutions for persistent storage.

CommandStore

The CommandStore manages Commands that trigger changes in an application. It is particularly useful for tracking and replaying commands to ensure consistency or auditability. Comby includes an in-memory implementation, SQLite and PostgreSQL.

DataStore

The DataStore is used for storing and retrieving underyling data of an Asset, such as files or binary assets. Comby offers in-memory, file-system and MinIO implementations, providing flexibility for lightweight or distributed object storage.

CacheStore

The CacheStore provides temporary data storage to optimize performance and reduce the load on persistent stores. Comby supports in-memory and Redis-based implementations, making it suitable for use in distributed systems.