I was wondering if there is any documentation/guidance on using Saga's and the EventStore. Part of my confusion is that when you look at using a Service Bus like NServiceBus or MassTransit the too have the concept of a Saga. I know the EventStore itself does not have the Saga in the code but the CommonDomain project does and they work together. Do I use the Saga infrastructure in the CommonDomain/EventStore or rely on ServiceBus Saga support? Or could both be used together?
Your best bet for a saga example is on my blog: Part I and Part II
You're more than welcome to use MassTransit or NServiceBus for sagas. I have a simple implementation using CommonDomain because I was trying to avoid a dependency on those frameworks and because I wanted to leverage event sourcing to facilitate sagas.
Related
More than a question, this is an architectural dilemma that I am facing.
Is it a good idea to have REST wrapper around a Kafka Producer and integrate with it, instead of directly integrating with Kafka Producer in my code? I could use a generic interface for my higher classes, instead of using the KafkaImpl directly to keep it loosely coupled for the future.
If you have the option, I'd probably go for the pure-Kafka approach, since you'd get better throughput (the clients are very intelligent with respect to batching and futures).
I'm not sure you're decoupling your code by adding a rest wrapper; you're just adding another level of abstraction, adding maintenance burden and covering over some of the benefits of Kafka.
If you really need to use REST, you can make use of Kafka-Rest - no need to reinvent the wheel!
As mentioned kafka-rest-proxy will work.
I know plenty of people that wrap Kafka producer/consumers with Spring Kafka, Mirconaut, Akka, Quarkus, Lagom/Play just to name a few. Spring, specifically, has the messaging binders that can provide that "generic interface" feel.
These are all web frameworks, and putting an API / RPC abstraction layer on any code is definitely necessary in 12factor applications
Is there any industry standard framework available in the market for implementing Event Sourcing and CQRS (Command Query Responsibility Segregation) ?
You can use Axon framework in java
and Prooph in php.
For node.js environment where is two major frameworks which are actual maintained nowadays - ReSolve and Wolkenkit. These frameworks also contain integrated solutions for communication with front-end web page (SPA application).
There are back-end only libraries for eventsourcing for node.js, including Node-Eventstore and Node-cqrs, but it's more libraries than frameworks for production applications.
Note that I recommended to implement your own Framework in the comment above. However I can still refer you to Akka. Akka is an actor model implementation that comes with support for event sourcing. It is available for .NET, Scala and Java:
See:
https://getakka.net/articles/intro/what-is-akka.html (.NET)
https://akka.io/docs/ (Scala & Java)
I was researching the Java Flux API when I noticed from some tutorials that you can only subscribe to one publisher. Yet, I see a use-case where having multiple publishers to a single subscribe is useful: some sort of a data/message bus.
The only solution I found is encapsulating an array of subscribers and 1 publisher inside the bus.
My question is, which is the correct approach from a reactive point of view to this problem?
I'm interested in solving this by implementing my own Publishers/Subscribers etc. (using the Java 9 java.util.concurrent.Flow API) This project is for learning purpouses, not for production.
You can use Spring Reactor, an implementation of Java Publishers API. It has operators like concat(), merge() etc. to combine the Streams for a given Subscriber.
https://projectreactor.io/docs/core/release/api/
In the REST world, we have something like a Swagger Specification, which fully describes the contract over a REST interface boundary (between client and server). Those Swagger specifications can be used to auto-generate REST clients, but also to automatically generate documentation for your REST API consumers. These Swagger Specification, moreover, are also a valuable asset w.r.t. CI and versioning of your API.
I was wondering if a similar solution exists in the asynchronous Publish Subscribe world: let's say a typical AMQP Consumer/Producer on RabbitMQ....
Best regards,
Bart
FYI, currently looking into following solutions:
https://avro.apache.org/docs/1.7.7/spec.html
https://github.com/hopped/rabbitmq-avro
Just discovered this, and it is promising:
https://www.asyncapi.com/
CQRS is about separating commands and queries. We can add it easily using several patterns & technologies like Event Sourcing, DDD, NoSQL, etc... but is ServiceBus mandatory?
I'd say messaging and a service bus is optional.
CQRS simply means decomposing your application so that the Read and Write parts of your application can be optimized for the respective concern. Commands can be handled directy, even Events, if you decide to use them, can be dispatched synchronously.
A good reference for using an internal dispatcher is Greg Young's simple examle.
Update: Rob Ashton has just posted a very good article on what CQRS is and how not to make it more complicated than it actually is.
No serviceBus is not mandatory, it's simply one of the technologies that be used to implement CQRS, for example Event Pub/Sub. If anything, Event Sourcing & DDD have a closer relationship to CQRS than ServiceBus.
No. You can use CQRS without service bus. In your case you only need the command dispatcher and the query dispatcher