event-sourcing | Provides basic functionality for event sourced aggregates | Microservice library

First of all, regarding your handle, you're not stupid :)

A few points:

• In many situations you can query the read model even though there's eventual consistency. If you reject a command that would have been accepted had a pending update become visible in the read model, that can typically be retried. If you accept a command that would have been rejected, there's often a compensating action that can be applied after the fact (e.g. a delay between ordering a physical product and that product being delivered).

• There are a couple of patterns that can be useful. One is the saga pattern where you would model the process of a purchase. Rather than "user A buys product X", you might have an aggregate corresponding to "user A's attempt to purchase product X", which validates and reserves that user A is able to buy X and that X is able to be purchased.

• Every write model with an aggregate implies the existence of one sufficiently consistent read model for that aggregate. One can thus define queries or "read-only" commands against the write model. CQRS (IMO) shouldn't be interpreted as "don't query the write model" but "before trying to optimize the write model for reads (whether ease, performance, etc.), give strong consideration to handling that query with a read model": i.e. if you're querying the write model, you give up some of the right to complain about the queries being slow or difficult. Depending on how you're implementing aggregates this option may or may not be easy to do.

Answering my own question, but really the answer came from a discussion with Christian at Axon. (Will leave this open for a few days to allow for better answers, before accepting my own :))

My options #2 and #3 are the right answers: the difference depending on how different my "summary" projection is from my "detailed" projection. If they're close enough, option #2, if they're different enough #3.

Option #1 is non-ideal, because even if we were using state-stored for some other reason, basing queries on the state-store breaks the Segregation that is the 'S' in CQRS: it makes our query model depend on our command model, which can lead to problems when our model gets more complex.

(Thanks Christian)

In general, the only reason to include data in a particular aggregate is if that data affects command validation or if there's some other consistency demand. if information about categories or users isn't qualifying under either reason, then it makes a lot of sense to remove it from the announcement aggregate.

I would probably consider modeling a "categorized and associated announcement" aggregate which is fed by domain events from announcement/category/user aggregates. This could be implemented via the multistream projection from your event store, but I think it's useful to keep that detail separate because there are other ways you could feed domain events from multiple aggregates as commands for a different aggregate (the command implicit in any event is "incorporate this event into your view of the world").

Both products are based on Kafka and Strimzi.

Red Hat OpenShift Streams for Kafka is a hosted solution. It's not free cost (although there are free trials for developers).

AMQ Streams is also based on Kafka and Strimzi but is customer hosted and managed. As you point out it's part of the overall integration bundle (so is therefore also going to include other related components like Debezium.) It has a more traditional cost model around number of cores that you use.

It seems you are referencing a class name that doesn't exist in the project source. You may use the following command instead.

As soon as you have separate data models for reading and writing, you're following CQRS. Event sourcing is not strictly required.

Note that accomplishing 1 in an application in a way which preserves the expected eventual consistency of the read side with the write side is rather difficult. You'll need to ensure that you publish the event if and only if the update of the write DB succeeded (i.e. there's never a case where you publish and don't update nor is there ever a case where you update but don't publish: if either of those could happen, you cannot guarantee eventual consistency). For instance, if your application does the update and if that succeeds, publishes the event, what happens if the process crashes (or you get network partitioned from the DB, or your lambda exceeds its time limit...) between the update and publishing?

The 2 best ways to ensure eventual consistency are to

• update the write side DB by subscribing to the published event stream
• use change data capture on the write side DB to generate events to publish

The first is at least very close to event sourcing (one could argue either way: I'd say that it depends on the extent to which your design considers the published event stream the source of truth). In the second, remember that you've basically lost all the contextual domain knowledge around the what's happened around that event: you're only seeing what changed in the DB's representation of the model.

Event sourcing and CQRS mutually improve each other (you can event source without doing CQRS, too, though it's only in certain applications that ES without CQRS is practical); event sourcing tends to let you keep the domain front-and-center and since it's append-only, it's the most optimized write model you can have.

Not your fault: the literature is a mess.

Domain events, event sourcing, and event driven are three different ideas that happen to share the label "event".

Domain events are a domain modeling pattern; in effect making "things that happen" a first class citizen in your domain model. Think BookSold, not MouseClicked

Event sourcing is a data modeling pattern; instead of having a domain entity with mutable properties, we have a domain entity with a history of changes.

Event driven is a communication pattern; system A publishes an event, and system B reacts. Notice that system A and system B don't even need to know about each other; the only need a common undertanding of the event, and shared plumbing (aka middleware).

In CQRS, when using EventStoreDb, your aggregate must be designed to be restored to a state from Events. Events are stored in a stream with a unique name and identifier (guid). When modifying the aggregate, you must read this stream, and apply each event in sequence to restore the current state, before executing any changes to the aggregate (which generates more events). In order to maintain integrity and handle optimistic concurrency, you should have a simple version check in your aggregate which counts the old events + new events to ascertain to latest version number to be persisted.

The issues I see above are as follows. Your aggregate has a constructor and a static method which generates events without any validation of the current state i.e.: What happens if I call create twice with the same guid?

this.apply(new UserCreatedEvent(guid, {email, name}, new Date()));

You are applying state here directly. Instead, you should raise the event inside your Create method.

this.raiseEvent(new UserCreatedEvent(guid, {email, name}, new Date()));

This should be implemented to do the following.

• Added to a list of uncommitted events
• this.apply called

You should then persist the events to the EventStoreDb in your command handler.

Event Source is not replacing the DB. It has some benefits and challenges. So, we should choose it wisely. If you are not comfortable then don't choose it. You can implement Microservice Style without event sourcing.

Query able DB - Simple solution is to implement CQRS pattern and keep your Query DB in sync with Event Source DB.

Event DB should be with owner service like if you are keeping events about Order than it should be in Order service. (Yeah, other service can have replica of the same).

You may use Kafka as intermediate storage for event but not the final one.

CQRS is not about one DB. It an pattern where we use to DB models, one is for Command and Another one is for Query.

If you understand Java then please refer Book "Microservice Patterns - Chris Richardson" and if you are from C# or Microsoft technology stack then you may refer "https://github.com/dotnet-architecture/eShopOnAzure".