search

pcah / python-clean-architecture

A Python toolkit for applications driven by The Clean Architecture
MIT License
442 stars 42 forks source link

Domain: changes to an Entity instance as a source of domain events #63

Open lhaze opened 4 years ago

lhaze commented 4 years ago

Elaborate and implement a simple approach in which Entities can support eventsourcing.

Part of #40

lhaze commented 3 years ago

@pedro2555

If I may. Domain events and sourced events (from eventsourcing) are completely opposite to each other. A sourced event describes a change to be done…

Firstly, thank you for your note, even when you have removed it. It has helped me to refine what I was thinking of opening this issue. Secondly, I'm sorry you had to wait for the reply. I was on vacation after intensive work-time during COVID. Thirdly, let me clarify what I had in mind.

By the topic of this issue, I meant how to connect eventsourced Entity with another eventsourced Entity using domain events. Yes, you're right when you say the two kinds of events have different purposes. Domain events are unquestionable messages about facts that already happened, a way to provide means of loosely coupling distant places of the system.

On the other hand, eventsourced events are internal detail of an entity implementation. They can and should be stopped when the operation is invalid or unreasonable. In terms of Event-Driven Architecture, they can be identified as Command pattern.

When I was creating this issue, I hadn't had that idea well-thought. I hadn't considered the distinction between domain events and commands. Now I see a Context Gateway pattern which servers as a translation middleware between domain events (preferably from the distant parts of the system) and local context's commands. Command handlers/interactions turn these commands into mutative operations of the local entity, which represents its inner state by an eventsourced event.

Although the picture I'm trying to describe may sound complicated, I have to take into account designs of significantly complex contexts -- I work on banking systems on a daily basis. On the other hand, every pattern besides basic ones (Interactor, Entity, eventsourced Event) is optional.

pedro2555 commented 3 years ago

In terms of event sourcing. Process Managers and Sagas manage the translation you're talking about, they translate events into commands. Further more they also apply compensations for failed commands, or yet more commands; which in turn may generate more events and so on.

For cross context communications a canonical model of events and commands may prove useful in larger system, or even smaller ones.

You'll find long discussions about process manager and sagas and their differences, and with that a lot of disparity. From my, I should say small, experience the only diference is state. Sagas have no state; works fine.