These are chat archives for eventflow/EventFlow

Jan 2017
Marco Monducci
Jan 05 2017 11:17
Hi, while I was deep looking at the EventFlow.Examples.Shipping project I collected some questions, is this the right place to place them?
Marco Monducci
Jan 05 2017 11:45

Hi, while I was deep looking at the EventFlow.Examples.Shipping project I collected some question, is this the place I can raise them?

  1. Entity / Aggregate Modelling

    Under the folder Domain / Model / CargoModel I've found the following structure (tell me if I understood correctly):

    • Entities folder containing all the "other" Entities
    • Cargo.cs definition of the Main Entity
    • CargoState.cs definition of the State of the Cargo Entity
    • CargoAggregate.cs definition of the Aggregate wrapping the CargoState.cs

      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 properties: Route and 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 IEntity<TIdentity>?

  2. EntityId

    Talking about Cargo and Voyage, why CargoId derive from Identity<CargoId> while VoyageId derive from SingleValueObject<string>?

    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?

Rasmus Mikkelsen
Jan 05 2017 12:50

Hi @MonDeveloper

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 (

2) 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

Marco Monducci
Jan 05 2017 13:30

So, if I got correctly,

  • the Cargo Entity does not play any role in the write model
  • ok for the question about EntityId

Thanks for everything @rasmus

Rasmus Mikkelsen
Jan 05 2017 13:37
@MonDeveloper nope, the Cargo entity is for reading data only, all writes to the CargoAggregate are done through commands
Rasmus Mikkelsen
Jan 05 2017 19:06
@MonDeveloper Just to clarify, I use the entities as immutable representations of the domain that are queried using the 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.
Rasmus Mikkelsen
Jan 05 2017 20:03
the "getting started guide" has been updated, view it here:
the entire documentation HTML site is available for download on the GitHub releases page