What you use them for is up to you. The equality of an entity is defined by its ID, thus if the ID is the same its the same object, even if the properties are different (might just be from different points in time). This is different from value objects for which all properties needs to be the same before they are considered equal.
The shipping domain example within the source code is very limited and only has a few scenarios built-in. In the few examples that there are, the entities are used as a materialized read-only version of the aggregates that can be passed to others. Updates to aggregates are done trough services.
I guess you could use entire entities for write as well, but then you'll have to calculate the "diff" between the entity state and the actual aggregate state and create any commends/events missing, while handling multiple writers (could be done using versions). In short, I wouldn't recommend it, better be explicit with commands invoked directly or using some domain service.
Please note that the area of DDD/CQRS/ES is very opinionated, what you see in EventFlow is just my interpretation.
Read model 'XxxView' is interested in these aggregate events: XxxProvided, YyyCreated, ZzzProvided Loading events starting from and the next 200 for populating 'XxxView'.
Hey - quick question here as well... also concerning SAGAs :-D ...haven't used them yet due to a lack of understanding. But: am I right with the assumption, that I should use ISubscribeSynchronousTo<>, whenever I want to do some subsequent action triggered by an aggregate event which is - simply spoken - not aggregate-related (like e.g. sending an email, calling an external API...) - and use SAGAs, when I want to do some subsequent aggregate-related action (according to https://docs.geteventflow.net/Sagas.html)
Regarding https://docs.geteventflow.net/Sagas.html: SAGA for creating the order, making a reservation, making a payment and ISubscribeSynchronousTo<> for sending a confirmation mail to the customer ?
Hi @ProH4Ck .
Seems like you are trying to have some unit of work, that ensures that a condition is true. In very large applications these locks on objects tend to be bottlenecks and could lead to slow performance.
Personally you should try to minimize communication/requirements between aggregates as each increases the domain significantly. Better try to find some way to model the "invalid state" and handle it gracefully. Either by cancelling (another event after, not deleting the previous), mark the aggregate as unfinished/transitioning while some state isn't valid. Or even modelling the state in the domain.
The textbook example is from banking. Instead of ensuring that there's money in the account before withdrawing any money, you simple apply an interest and lend the money.
Remember that everything in commands, and thereby also in aggregates, should be limited to domain validation and emitting events as it might be retried (automatically done by EventFlow) if some other thread/request changes the aggregate in the mean time.
Not a precise answer, but I hope it gives you some ideas.