Traditional Domain Aggregates + Event Sourcing

[tatemz]

I learned what I know about Event Sourcing from @gregoryyoung who has a lot of older material and CQRS examples on the subject. I think Livestore is a great solution for getting developers familiar with the patterns and principles. The strong type-safety is great, too!

I have setup a sample repo here showing the ES concepts I am wanting to discuss within this thread: https://github.com/tatemz/es-poc

---

I have a question related to traditional domain aggregates. From my limited experience in Event Sourcing & DDD, domain aggregates are the result of a pure left-fold over events for a given domain entity (example).

I think where I am having trouble is with Livestore materializers. To me, materializers are great at subscribing to events and building projections, but it is a well-documented idea that projections and aggregates are different concepts.

---

Why do aggregates matter?

Aggregates could allow end users to apply events to a domain object and preview them before committing/saving. This also allows for easy rollback to an aggregate version.

Livestore seems to support a lot of event sourcing concepts out of the box, but does it support traditional domain aggregate concepts? Should it? Or was it an intentional decision to not? Or perhaps is there a suggested workaround?

I would hate to have to setup a materializer to build an eventsByAggregate table because that would feel like it is duplicating the entire event log.

export const tables = {
  eventsByAggregate: State.SQLite.table({
    name: "eventsByAggregate",
    columns: {
      aggregateId: State.SQLite.text({ nullable: false }),
      name: State.SQLite.text({ nullable: true }),
      args: State.SQLite.text({ nullable: true })
    }
  })
}

const insertEvent: Materializer = (_, context) =>
  tables.eventsByAggregate.insert({
    aggregateId: context.event.args.id,
    args: JSON.stringify(Schema.encodeSync(context.eventDef.schema)(context.event.args)),
    name: context.event.name
  })

const materializers = State.SQLite.materializers(events, {
  UserCreated: insertEvent,
  FirstNameUpdated: insertEvent,
  PhoneNumberUpdated: insertEvent,
})

const queryEventsForAggregate = tables.eventsByAggregate.select().where({
  aggregateId: "user-001",
  name: { op: "IN", value: ['UserCreated', 'UserCreated', 'PhoneNumberUpdated']}
})

---

Check out my sample repo for a demonstration of where my brain is at. https://github.com/tatemz/es-poc

Thanks for all the hard work on a great project!

[IGassmann]

Hey @tatemz! Thanks for your question. I've been deep in exploring Event Sourcing and CQRS for most of the past year, so I'm always happy to discuss the subject.

Before answering your question, let us align on a some event sourcing/CQRS concepts just so we can more easily understand each other:

• Aggregate: A consistency boundary — a single transactional unit that enforces business invariants, accepts commands, and emits events. It state is rebuilt by replaying its event stream.
• Event Stream: An ordered, append-only sequence of events belonging to a single aggregate instance, representing the complete history of state changes for that specific aggregate.
• Event Log: A append-only storage of all events, which can span multiple event streams.
• Projection: A transformation process that reads events and builds a specific representation of data, optimized for a particular use case.
• Projector: A function or process that listens to events, executes projection logic, and updates one or more specific representations of data. In LiveStore, a materializer is a projector.
• Read Model: A query-optimized data structure built by projections, serving the read side of CQRS.
• Command Handler: An orchestration component that handles infrastructure concerns — loading the aggregate state, invoking the decider, and persisting the resulting events. It has side effects and interacts with external systems.
• Decider: A pure, functional abstraction that encapsulates an aggregate's business logic through three pure functions: decide (command + state → events), evolve (state + event → state), and initialState. It contains no side effects or infrastructure concerns.

---

How LiveStore Maps to These Concepts?

In LiveStore, the store is the consistency boundary. It combines an event log and a state DB that are strongly consistent with each other within a single client session.

Because of this design, a store functions as a single aggregate where:

• The event log serves as the event stream
• The state DB serves as both the aggregate state and the read model
• Materializers are projectors that build the state DB from events

---

Aggregates in LiveStore

To answer your question: I believe LiveStore does support aggregates — but in an implicit way. Rather than requiring you to explicitly define aggregate entities, a LiveStore store is the aggregate. The consistency boundary, event stream, and state reconstruction are all built into the store itself.

This should mean you don't need to set up an eventsByAggregate table or manually fold over events to rebuild state — LiveStore handles this for you through materializers that keep your state DB in sync with the event log.

If your domain requires multiple aggregates (e.g., User, Order, Product as separate consistency boundaries), you could use the multi-store API. Each store would act as its own aggregate with its own event log and state DB. Check out the web-email-client example for a practical demonstration.

---

That said, I'd love to hear your thoughts on this mental model. Does it align with how you're thinking about your domain? Are there specific use cases you have in mind that might not be well supported yet or feel unergonomic with the current LiveStore API? Your feedback would be really valuable as we continue to refine the developer experience.

[tatemz]

Thanks for putting time into your reply. Your explanation helped me understand how Livestore models state, events, and materialization.

At the same time, I’m still trying to reconcile how Livestore draws the line between projections and aggregates. Right now they feel a bit conflated since both come out of the same materializer pipeline and the boundaries aren’t as explicit as in traditional ES/DDD.

The other things I’m thinking through are:
• how aggregate snapshots would fit into the Livestore model, and
• how aggregate versioning would work (or need to be implemented) when treating a store as an aggregate boundary.

I’m going to put together another POC using Livestore that mirrors my usual ES workflow and compare it directly against a vanilla ES approach. That should give me clearer, more grounded questions.

I’ll post another reply once I have that ready.

In the meantime, check the 3 resources I posted in my first POC

• SimpleCQRS (m-r) - Greg Young's canonical CQRS example
• CQRS Documents - Foundational CQRS/ES documentation
• CQRS FAQ - Common questions about CQRS and Event Sourcing

Also this Q&A has good questions on versioning! https://www.youtube.com/watch?v=LGjRfgsumPk

[cortopy]

I’ve been exploring similar questions while evaluating Livestore. I am currently using it in a new dashboard tool serving as a projection for event-sourced stores in other systems. I would love to fully replace my existing infrastructure with Livestore, but I have hit the same roadblocks mentioned in this thread. Specifically, the concept of "The Store is the Aggregate" feels problematic for production Event Sourcing patterns.

The Consistency Boundary Problem

In traditional DDD/ES, an Aggregate serves as a consistency boundary. It ensures that business invariants are maintained within that specific entity. However, Livestore treats the entire Store as the consistency boundary.

This conflation creates issues with optimistic concurrency control. In Livestore, validation seems to rely entirely on the global sequence number rather than the aggregate version.

Consider this scenario with two aggregates (id: 1 and id: 2):

- seq: 1, id: 1, version: 1
- seq: 2, id: 1, version: 2
- seq: 3, id: 2, version: 1
- seq: 4, id: 2, version: 2

If I attempt to publish an event like seq: 5, id: 1, version: 1, a standard Event Store should reject this transaction because id: 1 is already at version 2 (Optimistic Concurrency Exception). However, because Livestore focuses on the global seq, it appears to accept this event simply because seq: 5 is the next valid integer in the global log.

Without a distinct concept of aggregateId at the persistence layer, enforcing domain invariants becomes difficult.

The "Store per Aggregate" Solution

The logical workaround—and the "Cloudflare way"—would be to map 1 Aggregate → 1 Store → 1 Durable Object.

This architecture would unlock the massive potential of Cloudflare Durable Objects, allowing for patterns like "database-per-user" where data is co-located closer to where the user is making requests from. In this setup, the specific Store instance correctly acts as the consistency boundary.

However, Livestore does not seem to support this dynamically:

1. API Limitations: The configuration assumes a static 1:1 relationship between the sync handler and the event database binding. There isn't a clear way to pass a dynamic aggregateId to resolve a specific Store/DO instance.
2. Siloed Projections: Livestore’s projection system excels at turning a stream of events into a queryable table. If we shard events across thousands of Aggregate Stores, we lose the ability to project a global view.
3. Missing "Meta-Projections": To query "all orders by user ID" across sharded stores, we would need to stream events out of the individual Stores into a centralized read model. This requires a robust internal pub/sub or outbox pattern, which is currently missing from the Livestore (and raw Cloudflare) ecosystem.

Right now, utilising Livestore feels like accepting a monolithic consistency boundary, which negates the potential benefits of distributed systems and architectures like those of serverless environments.

Having said that, I'm enjoying using Livestore for an app that syncs the data from other sources to the browser for an offline application. It really is quite something! But at the moment I don't see how I can use it for anything more unless I went all in towards a more monolithic approach.

[IGassmann]

Have you had a chance to look at LiveStore's new multi-store capabilities (available in v0.4.0-dev.x.)? It sounds like this might address the "Store per Aggregate" pattern you're describing. With it, you can have multiple stores in the same application, each with its own event log and state database. The store's storeId would correspond to an aggregateId.

Regarding your specific concerns:

Consistency boundary: With multi-store, each store maintains its own seq, so optimistic concurrency operates at the store (aggregate) level, not globally. If you have a thread-123 store, its seq tracks only that thread's events.

Dynamic store resolution: The web-email-client example demonstrates multi-store capabilities with 1 Aggregate → 1 Store → 1 Durable Object. In it, Thread stores are created with dynamic IDs (thread-{threadId}), each mapping to its own ThreadClientDO instance.

Cross-store communication: The example demonstrates a pattern for this:

1. Change detection – Subscribe to store table changes (will be updated to use store.events() soon)
2. Event publishing – Publish cross-store events to a Cloudflare Queue
3. Event consumption – A Queue Consumer Worker processes events
4. State update – Worker calls methods on other stores to commit events

We're aware that implementing such pattern requires some boilerplate, and providing built-in primitives for cross-store communication is something we're actively considering. I'm curious to hear if this pattern would address your use case, or if you see gaps that we should prioritize.

Did this properly address all your concerns, or are there specific points I missed or that need more clarification?

[cortopy]

Hey @IGassmann, thanks a lot for the detailed answer! And apologies for the delay, the holidays got in the way.

The web-email-client is an excellent example I missed when exploring Livestore. It definitely clarifies the intended architecture and I'm sure it will help others that discover Livestore for the first time in future. But I’m not convinced it fully solves the consistency boundary issues inherent to distributed systems on Cloudflare. At least not in its current form.

I see two distinct problems that standard "Store" semantics don't yet address out-of-the-box:

1. The "At-Least-Once" Problem (Idempotency)

When this line processes an event, we are at the mercy of Cloudflare Queues' at-least-once delivery guarantee. A retry (due to network blip or timeout) could cause the same event to be applied twice. I know it's very unlikely, but last year serious incidents in the Cloudflare infrastructure taught some of us that this can indeed happen. Not all stores are equal though:

• For "Set" operations (e.g., updateTitle), this is often benign (convergent).
• For "Delta" operations (e.g., incrementCounter, depositFunds), this is critical.

The Command RFC you're working on sounds like it will solve "check-then-act" consistency (e.g., "reject if email thread exists"), but it doesn't solve replay duplication.

My two cents: We need a way to enforce Idempotency at the aggregate level. In previous event-sourced systems, I've solved this by attaching a unique deduplicationId (UUID) to every event. The reducer can then track processed IDs in a local SQLite table.

If Livestore exposed a standard field for this in the event schema, we could protect non-idempotent reducers in some form or another.

2. The “Missing Event” Problem (Reliability)

This is the inverse problem: what if the event isn’t delivered at all? Logic like this push implementation in the email example works 99.9% of the time, but if this line throws, perhaps because Cloudflare Queues is down or rate-limited, the event is lost forever. The domain aggregate that consumers the events will fall permanently out of sync. Maybe event 5 is not sent to queue due to error, but 6 and 7 are.

My Two cents: The Transactional Outbox Pattern

I believe the robust solution here isn’t just a “table of subscriptions” but a formal Outbox Pattern leveraging Durable Objects’ SQLite + Alarms:

1. Commit Phase: When an event is generated, do not  queue.send()  immediately. Instead, inside the same SQLite transaction as the state update, insert the event into a local outbox table. This insertion should be part of a transaction in itself, where either both store.commit and sql.exec succeed or none does.
2. Async Phase: Schedule a DO Alarm ( state.storage.setAlarm() ).
3. Delivery Phase: The Alarm wakes up, reads from the  outbox table, and attempts the  queue.send() .
   • Success: Delete from outbox.
   • Failure: The Alarm naturally retries with exponential backoff.

This guarantees atomicity: either the state updates AND the event is queued for delivery, or neither happens.

In a system with a lot of writes this may increase the cost a lot since Cloudflare charges per execution. A variant of this pattern could be a permanent table that tracks subscription name and offset. This could allow sending a batch of events in each execution instead of one by one. It would also facilitate monitoring since we immediately get a way to query if all subscriptions are up to date.

I realize these patterns (Idempotency & Outbox) might be “userland” concerns, but given that Livestore aims to be a robust foundation for state, having first-class support (or at least documented recipes) for these reliability patterns would be a game-changer for production confidence.

Also, I've been working myself on a couple of libraries to do things like this (without Livestore). I haven't published anything because they're rather rough for public consumption but happy to share anything that can help in this space.

Thanks again for the great work on this!

[IGassmann]

Thanks for the detailed analysis! You've identified real gaps in the web-email-client example.

As you noted, both concerns appear to be solvable in userland today. The transactional outbox pattern you described is one solid approach, and there are alternatives worth considering as well (pull-based sync, notification patterns, etc.).

We're still exploring cross-store communication patterns and intentionally haven't committed to built-in primitives yet. We want to see how different userland solutions play out in practice before settling on abstractions. We want to avoid cornering ourselves with premature standardization here.

That said, the web-email-client example would definitely benefit from being updated to handle these concerns. It would serve as a better reference for production use cases. I've created issues to track this:

• [examples/web-email-client] Handle duplicate cross-store events #971
• [examples/web-email-client] Handle failed cross-store event publishing #972

Would you be interested in contributing improvements here?