Production-ready library?

[cloudcompute]

Hi

Can we use it in production, stable enough? Is there any example which we can use as the starting point? Can we use Nats and/or Mongo, Postgres as an event store?

Also pl. tell about the production status of fmodel (written in Kotlin).

Thank you

[idugalic]

Hi @cloudcompute
This library and the Kotlin version library are production-ready and used in production.

It is a very lightweight library that uses the Type system of the language to achieve the robustness of your solution. Saying all that, there is a small chance to detect bugs in this library (especially on the Domain layer). Most are detected at compile time!

BTW, the libraries are regularly maintained and new features will be added.

Best

[cloudcompute]

Hi @idugalic

Wonderful ! More than this, thank you for remembering and sending the notification to me.

Recently, I tried to implement event sourcing using Scala language. I favour Scala for two reasons: a. Great built-in functional support b. its ecosystem is awesome especially ZIO

I am asking these questions in context of Kotlin (JVM based)

Would it be possible to use ZIO effects (allows us to interact with the outside world) along with this library?

I had a look at the Event Repository interface.. It seems like we can use any database.. for this do we need to implement this interface?

How have you implemented CQRS.. using the Outbox table pattern?

Thank you

[idugalic]

Hey, great. Scala is a very good fit IMHO. ZIO looks like a good choice.

I am not sure how ZIO and Scala will interop with the model (kotlin). It is better to port the whole fmodel lib to Scala, I think :)

I had a look at the Event Repository interface.. It seems like we can use any database.. for this do we need to implement this interface? -> Yes, you can implement these interfaces for any DB (or purposed event store).

Please refer to the demo https://github.com/fraktalio/fmodel-spring-demo. It is using Postgres as an event store and event-streaming platform to support event sourcing and CQRS (event streaming)

[cloudcompute]

Thank you, I will.

[cloudcompute]

Hi @idugalic

I am going through fmodel-ts and fmodel libraries.. the code is very neatly written. However, it will take some time to fully understand it.

What is EventLockingRepository about.. its purpose?

Do they support Optimistic Conccurency Control, I am almost sure they must be.. pl. confirm.

I want to implement the Outbox table pattern that allows us to write domain events in the underlying event store and a corresponding record in the Outbox table at the same time (in a single transaction). Where (which file/repository) do I need make those changes?

Thanks and Regards

[idugalic]

Yes. It is for the Optimistic Concurrency Control. I confirm that.

You can check this demo app.

The focus is on two functions within the repository:

• readonly fetchEvents: (c: C) => Promise<readonly (readonly [E, V])[]>;
• readonly save: (e: E, latestVersion: V | null) => Promise<readonly [E, V]>;

Please notice that fetch returns a list of pairs [event, seqNumber] for this command (command.aggregateId). This list of events is ordered by seqNumber. The largest seqNumber in this list represents the current version of that aggregate stream of events. It will be used as a second argument of the readonly save: (e: E, latestVersion: V | null) => Promise<readonly [E, V]>; function to implement optimistic locking. EventSourcingLockingAggregate is implementing handle method on this principles: check here

In the save function you can store a list of events in many different tables, in one transaction (maybe you have an SQL function to call, or maybe you want to use your favorite ORM), it is up to you.

[idugalic]

Additionally, I am sharing the blog post that is related to this topic optimistic locking

[cloudcompute]

Ohkay, EventSourcingLockingAggregate is all about OCC. Thank you for the quick response.

You have documented almost every part of the code including these blogs, I like this approach a lot.

TypeScript example is great.. the only thing I think I need to do is to replace Axon stuff with PostgreSQL and it'd be easy.. I guess.

In the save function you can store a list of events in many different tables ..

Here?

I was thinking about this architecture:

• A single microservice that is responsible for storing the events in the underlying event store: could be TypeScript because Node shines in I/O

• Other microservices handle the business domain logic/rules/validations etc. and then invoke the micorservice (mentioned above). Such microservices can be written in any language.. could be Java or Node.

To achieve this, we need to split this code in 2 parts:

a. Database operations (NodeJS/TypeScript) i.e. the single microservice

b. Domain logic i.e. the other microservices (Java, ..) that takes care of the business logic will invoke the single microservice

Right now, I am not sure whether it even makes sense. I am trying to figure out if it is possible. It'd be really great if you can throw some light on this.

[idugalic]

In the save function you can store a list of events in many different tables ..

Here?

Yes.

EventSourcing is splitting the whole domain model into two parts:

• Command (command handling, decision making, decider/aggregate) - it publishes events to some store.
• Query (event handling, denormalized, view/materialized view) - it handles events and projects them into denormalized views adequate for optimal querying

You might recognize this as a CQRS pattern. It effectively liberates you from having one canonical schema to rule them all!
You might want to deploy these two parts independently and write them in two different programming languages.
Please note that this split is per the Command/Query model. Both sides contain all the arch layers: domain(decider or view), application (Aggregate or MaterializedView), and adapters written in the selected language.

In the case of the Axon platform, you can split components per layer as well (and write them in different languages), as Axon distributes/dispatches commands and queries over the wire. This is known as Location Transparency. It means that the component that is dispatching the command is not aware of its handler (the Aggregate). For example, you can extract Web controllers as independent apps: they will simply dispatch the command, without knowing the existence of the aggregate.

[cloudcompute]

I am editing this comment..

Earlier, I was of the viewpoint that domain events should be mapped to integration events (Order and Customer events in this example) before writing to the event store. But I was not correct, this mapping should be done after saving the domain events to the store.

Please note that this split is per the Command/Query model. Both sides contain ... written in the selected language.

I didn't notice this split.

[idugalic]

Nice pic! This is the way! Here you have OrderEventSourcedAggregate publishing/storing events to DB, and Kafka streaming them to ShipmentSagaManager and/or CustomerSagaManager. These Sagas are within the Shipment/Order service, acting as an anti-corruption layer and mapping these events from Kafka into a command for the aggregate to handle: ShipmentEventSourcedAggregate and/or CustomerEventSourcedAggregate

[idugalic]

And, if you want you can map domain events to integration events while publishing them to Kafka. It is on you, if you want to make the separation: Events Inside vs Events Outside.

[cloudcompute]

It is on you, if you want to make the separation: Events Inside vs Events Outside.

Right !