cqrs | http : //cqrs.nu/ | Microservice library

All of these have "it depends"-like answers...

1. Yes, usually, although some implementations might choose to (try to) update read models transactionally with the update. With multiple nodes you're quickly forced to learn the CAP theorem, though, and so in many CQRS contexts, eventual consistency is just accepted as a feature, as the gains from tolerating it usually significantly outweigh the losses. I suspect the bit you quoted anyway refers to transactionally updating the write store with publishing the event. Even this can be difficult to achieve, and is one of the problems event sourcing seeks to solve.

2. Yes. It's trivially obvious - in this context - that data must be written before it can be read, but your apps as consumers of the data see them as read-only.

3. Both are valid outcomes. Usually this part is less an application concern and is more delegated to the capabilities of your chosen read-model infrastructure (Mongo, Cosmos, Dynamo, etc).

DDD and CQRS don't care about the framework you are using for db persistence.
In the sense that for DDD (the nearest part to the db persistence) has its way, commonly through the repository pattern, to abstract away the persistence.
So, theoretically you could just create your interfaces for the repositories and implement them using whatever thing you want.
What is important to DDD is that your implementation for the persistence respect the guarantees needed for the repositories (like storing an aggregate is an atomic operation), but if you can meet them, any implementation will make your domain work as expected.

About being a good fit, it depends on the benifits your situation can gain from using one or the other, spring data + hibernate are very easy to setup and use, and they also have a lot of automatism already implemented, with IBatis maybe you can write custom queries more performant, as most of the things in computer science, it depends.

I had the same issue, one of the reasons can be that your bean is brought by a dependency and to fix it you need to add an empty beans.xml in main/resources/META-INF in this dependency in order for Quarkus to discover the beans as indicated by the documentation

Relevant extract:

The bean archive is synthesized from:

• the application classes,

• dependencies that contain a beans.xml descriptor (content is ignored),

• dependencies that contain a Jandex index - META-INF/jandex.idx,

• dependencies referenced by quarkus.index-dependency in application.properties,

• and Quarkus integration code.

I see 2 problems in the configuration:

1. You just "build" the configuration, but don't start it. After buildConfiguration(), make sure to call 'start()' on the returned Configuration instance. Alternatively, directly call start() on the Configurer. It returns a started configuration instance.

   That should resolve the registrations not coming through. But it will probably trigger an exception related to the next issue....

2. Your MongoTokenStore configuration is incomplete. The TokenStore needs at least a serializer and a MongoTemplate instance. The latter tells the Axon which collections you want to certain types of information in. In your case, only the TrackingTokenCollection would be relant.

Axon Farmework provide something called Configuration API. You can have a look at the Configuration class but for making use of it, you need a Configurer, which will provide you all means of configuring your components!

On the ref-guide, you also have several examples of how to do the configuration using the API or Srring Boot. Example for Commands can be found here.

To help a bit more, I can also share a small project I made using Dropwizard and Axon Framework, meaning no Spring was used and all the Configuration was done through the API. You can find it here https://github.com/lfgcampos/axon-playground/tree/master/chat-getting-started-dropwizard

I don't think its a bad idea at all, you can create an interface for mark all the requests you want to implement the PipelineX, and other for PipelineY.

Ex:
You have the RequestOne and RequestTwo classes that need to go through PipelineX, so you create and interface like IPipelineOne and mark the classes with it, then use reflection to process inside the pripeline middleware. The PipelineY will still run through these two classes and the rest of the program as well with no problems

Even when the domain is light on logic, so to speak, the value that comes with modelling aggregates (in-memory persistence, constraints management etc.) and events (intent modelling, business transaction log + audit log, integration etc.) still apply. Additionally, the reasons for modelling command messages separate from event messages still apply (it's about the intent of the message and they can evolve independently). More-so, a domain light on logic, so to speak might not always remain so.

I think it might be possible, however to not have an explicit class representing the command handler. The command to aggregate mapping could be done in some other way.

However, for cases where the domain does not manage the constraints e.g. in the case where the events really are implicitly-external e.g. if the groups are managed elsewhere and simply need to be replicated to our domain, it should suffice to have only an event.

This leak is fixed in the MyGet build. Details here.

Should State Changes generated at the read side create more events?

"State changes generated at the read side" is a very... odd... spelling to use in the CQRS pattern.

In the usual arrangement, information from "the outside" is delivered to the write model, and that's where we perform our computation to decide what the new "authoritative" state of the entity is.

The read model is a non-authoritative copy of state; accurate as of some point in the past, but not necessary up to date. Think "cache".

State changes generated by the cache is weird, because the cache is reflection of the write model.

Now, what will sometimes happen, is that we have two models, and the second model will be interested in changes that happen to the first model.

In that case, we use some form of plumbing to connect the outputs of one model to the inputs of the other.

So we have Alice doing her work, and one of the reports (read model) produced by Alice's work becomes one of Bob's inputs as he does his work.

Now, you might -- as a matter of optimization -- broadcast "events" when the caches update, so that subscribers can know that there is information available for processing. But you probably shouldn't be framing these as "state changes" in the sense of being changes to the entities in your domain model. Those changes have already happened, under the governance of the write model.