About edomata-example

[nkgm]

Hi @hnaderi, thanks for publishing your work, it has been of immense help and a gold mine of information.

I was wondering if you could amend the accounts example with a TransferMoney command, similar to the Process Managers example here.

I am also a little confused about the separation between Event sourcing and CQRS style. I understand CQRS does not necessarily imply ES, and I found some explanation in another discussion, but it would be really helpful to also have a complete CQRS/ES example in the same App.

[hnaderi]

Hi @nkgm,
Thank you for the kind words, I appreciate it!

On separation of event sourcing and CQRS, event sourced state machines are state machines that reconstruct their state using events on read, meaning that each event models a transition to a new state; while CQRS state machines just manage their state directly on write, without any events and their transitions are not as well-defined compared to an event sourced state machine. Both can publish external notifications at every interaction (no matter if the command is accepted or not) with the aggregate.
Also note that while the event sourcing definition I mentioned is widely accepted, the CQRS definition is merely my framing of the problem, while almost all event sourced applications are also CQRS, the CQRS applications that aren't event sourced are most of the time simple state based applications that only require an outbox to notify other aggregates and processes of some of the decisions they have made.
About your suggestion of having a complete ES/CQRS example in the same app, the example project contains an event-sourced (accounts) and a CQRS style service (orders). What kinds of extra examples would be helpful?

Also, about the first request, I would be glad to help, however I think it's out of the scope of the example for a couple of reasons:

• Implementing a process manager is a different task from implementing business logic in an aggregate. It requires working with database and streams, which are external tools to the library. Having an example of that part of the application in the example project is both misleading and unnecessary.
• It also complicates maintaining it for both cats effect and ZIO that use quite different tooling and styles which need to be replicated again so that not to cause more confusion.

Having said all of that, I would be happy to help if there are specific questions or problems.

[nkgm]

Hi @hnaderi,

About your suggestion of having a complete ES/CQRS example in the same app, the example project contains an event-sourced (accounts) and a CQRS style service (orders). What kinds of extra examples would be helpful?

The edomata-example is actually 2 unrelated apps. It would be good to have a CQRS/ES AccountsApp for example.

Also, about the first request, I would be glad to help, however I think it's out of the scope of the example for a couple of reasons ...

I guess the question then becomes: can we do this without a process manager, and how would we do it in a CQRS/ES AccountsApp?

About your other point, I do understand it's not within the scope of this library, but it would still be a valuable addition. As to it being confusing, edomata-example already has separate catsEffect and zio implementation modules, so the distinction would be self evident IMO.

On complexity and maintenance, I fully empathize and couldn't ask you to expend more time than you already have (even though a quick and dirty gist of a catsEffect process manager would be super helpful 😅)