Activities tie events together. Receiving an event triggers an activity that triggers downstream events. In this video, learn how about activities by adding them to your event map.
- [Instructor] So, now that we have some events on the board, we can start thinking about what to do when the events occur. When the cart is purchased and then the order is accepted, there's things that have to happen in-between that. So let's start adding some commands, some activities. So you remember from earlier that these kinds of activities are blue. So once the card has been purchased, we have to issue an invoice, that could be something as simple as just displaying it on the screen, but remember, we're staying in the domain here. So as we're working, I'm working in a, what's called a metaphor, that being a manual process where there's actually real people doing the actual work in the physical world. Of course we're not going to be doing it that way when we implement but the way we think about this is that we're moving the physical world into the computer. The activities that occur in the physical world will also be happening inside the computer as we're working. So I issue an invoice, and the other thing I'm going to need to do obviously is request a payment because we can't accept a payment until we've requested it. So let's add a request payment event. Now again, notice that these are stacked vertically which means that they can happen at the same time. The next order of business is we now have to actually process the payment and I'm not sure what the best way to do that is. So the payment processing is going to be an external entity. I know that as a fact because I've done this kind of work before, and you second source your payment to a payment process or service of one sort or another. So we need an external entity here that's going to be doing the work. The external entities are pink, so let's grab an external entity here. And that would be our payment processor. The request payment then is going to delegate work to our payment processor so let's just draw an arrow in order to indicate that that's happening here. And I'm not sure exactly what's going to go on here and I don't really want to stop the flow of my work so I'm going to leave myself a note just to remind myself that there's more to do here than I'm thinking of. How does this happen. So red, remember, is for all of the notes, all these things that have to be filled in later in order to be able to complete the system. After the payment has been processed, then clearly we're going to have to accept it. So that's going to go up here to the payment accepted. And then we can move forward. Now, moving to the right then, what do we do after the payment is accepted? I need a little more space. Let's move all of these guys over. This is why you want to use those super-sticky sticky notes by the way, you start moving normal sticky notes around and they'll stop sticking after a while. Once the payment is accepted, then I need to send a receipt and I need to authorize the shipment. So now we can actually start thinking about actually doing the shipping. Actually, let's flip this over because I know that authorized shipment is going to be impacting the flow up here so if I put it on the top, it's going to make the diagram read a little bit more easily. Now once I've sent the receipt to the customers, there's really not much else to do in this particular flow. So the flow of activities effectively stops here is that will continue this flow but up to this point, we have what amounted to two parallel flows. There's no official notation for that but what I do is I just use a big X just to indicate, all right, this flow is finished.
- How DDD differs from other architectural approaches
- How DDD fits with agile
- Advantages of microservices
- Bounded contexts and entities
- Reactive vs. declarative systems
- Using event storming to develop a DDD architecture