Adopt aspects from Eventuous (The Right Way)

[tjuerge]

I really like your fully end-to-end approach with its thorough design and documentation. Great work.

But I would love to see in your solution the adoption of some aspects of Alexey Zimarevs The Right Way and its C# library Eventuous, e.g.

• Separation of (immutable) state management usable without aggregates
  • Required for getting rid of aggregates (behaviour) from the core of a generic ES implementation
• Support for functional domain models and functional services by using isolated lambdas instead of state mutation within aggregates
  • Functional programming helps in managing side effects, e.g. due to state mutations within multi-threaded applications
• Event Store support for real-time subscriptions usable for projecting read models or publishing integration events
  • For the (in Java land) missing C# (and go-lang) construct of Channels the Java-based CSP (Communicating Sequential Processes) implementation JCSP can be used

[eugene-khyst]

This feature request goes against the initial goals of this project.

The goal of my project is to show that event sourcing and CQRS can be added to almost any existing application with PostgreSQL database with little efforts. You can install and manage Event Store or buy their cloud solution and learn new approaches suggested by Eventuous but this is optional and you can stay with PostgreSQL and still have event sourcing.

I've never worked for Event Store company (like the author of the article you are referencing to), so I don't see any reason to promote their approach and vision. Also, I don't like clickbait headlines like "The Right Way". There are many ways with with their pros and cons.

I want my project be as simple as possible. I'm not building a Java-port of a C# framework.

[tjuerge]

Sorry, I didn't want to offend you.

The goal of my project is to show that event sourcing and CQRS can be added to almost any existing application with PostgreSQL database with little efforts.

As I said, I like your design and documentation. Unluckily your implementation is not usable for me - it's not generic, but closely coupled to Spring, which doesn't fit into my current tech stack.

[eugene-khyst]

If the problem is with the tight integration with Spring Framework, it's another question. I think I can make "core" Gradle module that will not depend on Spring, and then wire everything up with the Spring config. It will be possible to use another DI framework.

[eugene-khyst]

Spring Boot is still so much more popular than its competitors (according to Google Trends and Stack Overflow Trends) that I don't think it's reasonable to invest time into making the project framework-agnostic.

I will mention Spring Framework in the README as a precondition for using this project.

Of course, you can't use the project as-is if you don't use Spring. But you can create a fork and change Spring-related code to whatever framework you need. There is not many classes relying on Spring features.

[tjuerge]

Spring Boot is still so much more popular

No need to sell Spring to me - I've been using Spring in commercial environments since 2003 and helped to build the first tooling support ;-)

But luckily today there're other alternatives available than back in the old J2EE days. Newcomers (like Quarkus and Micronaut) may not be mainstream yet - but in the J2EE days it took Spring some time to get traction as well.

[eugene-khyst]

To have less confusion, I emphasis that the project is built with Spring Boot:

A reference implementation of an event-sourced system that uses PostgreSQL as an event store built with Spring Boot.