These are chat archives for eventflow/EventFlow
EventFlow.Examples.Shippingproject I collected some questions, is this the right place to place them?
Hi, while I was deep looking at the
EventFlow.Examples.Shipping project I collected some question, is this the place I can raise them?
Entity / Aggregate Modelling
Under the folder
Domain / Model / CargoModel I've found the following structure (tell me if I understood correctly):
Entitiesfolder containing all the "other" Entities
Cargo.csdefinition of the Main Entity
CargoState.csdefinition of the State of the
CargoAggregate.cs definition of the Aggregate wrapping the
I can appreciate the separation between
Cargo Entity and the
Cargo Aggregate but i'm wondering how to deal with the definition of
Cargo Entity and
Cargo State; I mean, from a modeling perspective the
Cargo class has 2
Itinerary (which in this case are
ValueObjects) and following this example it seams the developer must keep aligned these 2 properties among both
Cargo Entity and
Cargo State, am I the only one feeling this a bit tricky?
Likely the most appropriate question could be, Why the AggregateRoot is Generic only in itself and
TIdentity and not also on
CargoId derive from
VoyageId derive from
Both are the Key of the Main Entity and both are strings, I can't understand the difference in terms of meaning, could you help me?
You can ask here, I'll try to answer your questions, let me know if I'm off.
1) In the shipping example the entities always originate from a read model, never from an aggregate directly (the only place the
Cargo constructor is used is in the
CargoReadModel.ToCargo() method. This means that the cargo entity and the cargo state will not be in sync at all times as there will be some time before the read model is updated. I would recommend going for an eventually consistency model and rely on the subscribers to eventually propagate the information. Remember, there's no way to guarantee order between aggregates (http://docs.geteventflow.net/FAQ.html#why-isn-t-there-a-global-sequence-number-on-domain-events).
VoyageId should inherit from
Identity<VoyageId> for consistency, that's a mistake on my part. But as long as the type implements
IIdentityits valid. EventFlow tries to use interfaces as much as possible instead of forcing you to use some built-in types that might not suite your needs. The built-in
Identity<> is a good starting point, but you might want something else in some cases.
Hope that helps
So, if I got correctly,
CargoEntity does not play any role in the write model
Thanks for everything @rasmus
Cargoentity is for reading data only, all writes to the
CargoAggregateare done through commands
IQueryProcessor. How you use them (if at all), especially in combination with your commands, is entirely up to you and what ever coding style you have.