search

eugene-khyst / postgresql-event-sourcing

A reference implementation of an event-sourced system that uses PostgreSQL as an event store built with Spring Boot. Fork the repository and use it as a template for your projects. Or clone the repository and run end-to-end tests to see how everything works together.
Apache License 2.0
986 stars 84 forks source link

Separate ES-related infrastructure code from application code #8

Closed tjuerge closed 7 months ago

tjuerge commented 9 months ago

Currently the application code is entangled with the generic ES-related infrastructure code, e.g. the enums EventType and AggregateType are pulling-in domain-specific code into the generic EventRegistryand AggregateRegistry implementations.

For a simple example this is ok, but for a template of a production-grade application this could be improved - maybe by aligning to the architecture approach of Clean Architecture (as Tom Hombergs describes it in his blog post Hexagonal Architecture with Java and Spring and his book Get Your Hands Dirty on Clean Architecture ).

So I would like to suggest refactoring the ES-related infrastructure code from the application into it's own package or module.

cloudcompute commented 9 months ago

Hi, Documentation is great. Is the code production-grade/ready?

eugene-khyst commented 9 months ago

Yes, the code is production-grade. For simplicity, there is only one Gradle module. In the real applications it may have sense to extract the event sourcing infrastructure code to the separate Gradle module or even project. I plan to implement it soon. But it is more about project directory structure.

cloudcompute commented 9 months ago

Thanks for the response.

event sourcing infrastructure code You want to say that the generic code relating to event-sourcing (which mainly constitute these folders: config, repository and service) should be placed in a separate directory, am I right?

The code placed in the projections directory is domain-specific. Why have you decided not to make it generic. Is it because the projections are domain-dependent.. just like we can write different types of Queries for a given microservice/domain and therefore writing the generic code for the projection feature does not make sense?

eugene-khyst commented 9 months ago

For the event sourcing part there are quite a lot of generic code that can be reused by multiple domains if extracted into a separate Gradle module. Of course, there are also domain-specific code for event sourcing part (the concrete commands, events event handlers). Projections doesn't require any generic code because they completely rely on Spring Data JPA. All we need for projections are Spring Data JPA repositories and JPA entities.

Source code files will be split between Gradle modules the following way:

Infrastructure code (generic code)

Application code (domain-specific code)

@tjuerge , what do you think about splitting the code the way I described?

cloudcompute commented 9 months ago

Great.. and thanks