I don't think I'm going to be able to go in much depth with many of the questions, but I'll do my best to try to explain how I would think about them. I hope that I'm not too flippant about these concepts and send you in the wrong direction. I'm just unable to spend the time to consider them too deeply right now. 1. If you have a completely separate authorization system, then you don't have authorization events in your model. You simplify the Order model and you still can have employee ids communicating who made what changes, but a separate subsystem can handle authorization. There are many authorization frameworks you might even choose to use. 2. The Products type could just be an object that ensures that you've constructed a valid collection of Products. It could have convenience functions on it etc. In the code example linked in the description I seemed to have used an array. 3. Perhaps I would make it so that the Products are only ever loaded such that they're protected behind the correct tenant id. It's hard to say for me exactly how I might do this. But there ARE things you could do --for example-- include a tenant id in your event store (if that's relevant, I don't know), which would ensure that when loading event streams you're always limited to the correct tenant scope. I think you need to look at the various needs you meet and toy with the idea in order to find what's right for you.

@@ShawnMcCool thank you for the answer. And I wasn't expecting for a deeper explanation, I know this is a complex topic, this was already very helpful. What I got from your answer is that I can do those things is "several" different ways. I could have some Service that before building the Aggregate, let's say, placing the Order, makes all those check I talked about, and then the Order Aggregate is responsible only for the "Order" itself, meaning, it expects the data passed to it to already be "correct", because we know we used some "Middleware", for example, before reaching that code. So, about the correct Tenant data, I could assume, on my Domain code, that all data inside it has already passed through some Tenant check mechanism. I don't have to check it there. This would be specific to my use case. But for some other system, let's say, they might want to check Tenant inside a Aggregate... It all depends on the needs.

Thank you for the kind words. It's really nice to get a notification like this out of nowhere!

I don't mind relying on the event system being fairly up to date, as it's all monitored with alerts. You ultimately have to rely on the fundamentals of system. But it doesn't mean you shouldn't consider the network when it comes to implementation. Handling duplicated messages, messages out of order, and considering timeouts and delays are all important.

Also thank you very much for the reply. Probably you're right in that it would be clearer.

@@ShawnMcCool Awesome, thank you for pointing out these additional considerations.

That's a very nice thing to say to someone. Thank you so much, you made my day.

Thanks, I appreciate it mate!

If I understand correctly, you're suggesting creating relations for each event type. May I ask why you would want that?

@@ShawnMcCool No, that is what was described in the video. I was giving an alternitive which would be 3NF. A table of events, and a table for key value pairs for each bit of data associated with said event, the event type is a field within the events table for the event that has happned. Doing this can mean you don't need to create extra copies of data for things like the reservation pattern, as you already have the data normalised and able to query it in a effective way.

Yeah fun stuff! The state of an aggregate is a fold over the event stream.

Hi there, in relatively large scale systems we're using UUIDs. They can be indeed be stored as binary. Largely I don't think that the exact algorithm matters so long as it doesn't require any other knowledge in order to be generated. If they can be generated in isolation and be unique, it's fine.

@@ShawnMcCoolThanks for the feedback.

🥲Thank you so much. That's a very nice thing to hear.

Haha yeah. I remember when I learned that visibility was about knowledge encapsulation, it really made me rethink some things.

Thank you for the kind words! I worked hard on the series over the course of a year to put it together. I'm not particularly skilled at video production so it was a labor and to hear that you appreciated it means a lot. I really hope to make it to DDD Europe this year, it's my favorite conference. But it comes down to what my company chooses to do.

The arrow is when you call a method on an object. Like object.method() in another language. raise is a method that we built into the aggregate class that accepts and handles a new event.

Domain events are about business occurrences that need to be reacted to. If an address is corrected because it was incorrect or if a person moves to a new home, those might be interesting because the application needs to react to those events in order to trigger the correct behavior. You can't tell the difference between the two if the event is just address changed. It's about what kind of event needs to be reacted to, and not just what data changed. You can always react to enquiry opened by creating new specific effects that are generic, like a person's address changed, if that's useful. It's really based on your model of reaction.

There's a lot of paths. Sometimes, you can just get away with every mutation inserting or updating specific values and the result is that any event that comes in, you can project into the data set in a way that isn't sequence-specific. Another way is to store data for each mutation that comes in, and compare the values that have already come in before updates. Etc. I personally don't have one right way or right answer. I've seen a number of patterns work for different teams.

@@ShawnMcCool Would you capture a UUID for each event that is raised. Handlers can then use this for idempotency. This is a path that I have followed but not in an event sourced system and wondering if you think it is applicable. There is also concurrent processing of events. Borrowing from message brokers I assume that the aggregate ID can be used as a message group to partition processing. I am thinking about external systems or adjacent applications responding to these events e.g. when the order is completed that triggers the creation of a fulfillment process or an order fulfillment aggregate. But the fulfillment system has responded to the order aggregate domain event. I realise this is tangental to event sourcing.

@@Ffaarg7 yes this all makes sense. We tend to try to find an idempotency mechanism that doesn't require extra state storage. But if not possible then event id is useful. We use mutex locks on state changes to prevent concurrent processing.

Events are a decoupling pattern. You can use them whenever 'one thing happening' should trigger 'another thing'. Sometimes this is done by making a method call, you make a method call, get back a value.. maybe it's an entity or boolean or maybe you just ran a method and now know that it's time for 'the next thing'. This connection exists in code, in a specific place. In order to add anything (for example) you would need to modify that place in code. With events as a decoupling pattern, you can raise the event and then anywhere you can add an event listener to the dispatcher, you can extend the code with more behavior, without having to modify the exact place in the code where the event was dispatched.

Everything is a state machine you're right. :)

Another thought was about physical models essentially modeling regularities in the physical world similarly model probably can be thought of concepts defining regularities in a business.

This use case with the process manager seems interesting but also more complicated to maintain than an example above I gave ) It seems we need some sort of persistent storage anyway to be fault-tolerant here which means keeping at least one record in such storage (SQL, Redis, etc.) for each user. So as we already have a Cart entity for everyone maybe it is a good candidate for such state just. Anyway, interesting stuff, thanks for sharing! )

A cron job is an event. It's just not modeled as such. If your system has a cronjob triggering hourly events, daily events, etc.. then your various processes can listen to these events without adding more and more cronjobs.

@@ShawnMcCoolNL Yep, thanks!. This approach makes it flexible somehow. Would like to hear from you what do you think about my first comment. Is it possible/appropriate as some sort of alternative to process manager if we make a Cart an aggregate to raise own events?

@@pavelnemoi Yeah so, I've reviewed the video again and I'm not sure that cart isn't an aggregate already which raises its own events. That doesn't mean that the aggregate has to be responsible for everything that has to do with a Cart. An aggregate is about transactional consistency, the process of contacting someone whose cart is timed out can exist outside of that consistency barrier. In actuality, it's entirely possible that we don't even care to make a cart aggregate, because the consistency concerns just aren't there. Could you help me know more about what you're asking? I feel like I'm not getting a full picture.

@@ShawnMcCoolNL Got it, thanks! I am just curious about a possible case to avoid process manager somehow maybe for simplicity. Like cart raises its events like an aggregate and some listeners react (update read models, etc.). If we need to check abandoned carts we can have a cron job for example which queries the cart's read model and checks the product's state inside. If the cart is abandoned this cron job sends an email, etc. So the point is to avoid an intermediate state in database (process manager). I also don't see process manager as a too complicated approach, it is ok for sure but try to find a bit easier alternative maybe.