Hey there, welcome back. Before we move forward with the lessons, let's take a quick stop and see what we have started with, what changes did we make, and where we're currently at. I'm not great with diagrams, but I tried to make a few to explain what changes we made through software, especially at the CheckoutController and all the dependencies it uses. So let's take a look at those diagrams really quickly. This is how we started. We had a CheckoutController interacting with all these different actors. We were talking to the Product model to not only find the products, but also to update their stock.

We were talking to the Product model to not only find the products, but also to update their stock. We were talking to PayBuddy to charge a credit card. We were talking to the Payment model to create a payment record. And we were also talking to the Order model and to the OrderLine model to update records and create database records. And then we were also sending an email, the order received email. So as you can see from this very poor diagram, we had interactions spamming different modules. We had interactions within the Order module, where it's where the CheckoutController lives, but also interactions to the Product module and to the Payment module as well.

We had interactions within the Order module, where it's where the CheckoutController lives, but also interactions to the Product module and to the Payment module as well. And this is what we currently have. I tried to give each compound in a different color. Maybe that made it harder to see this, but we pretty much have the CheckoutController. And you see how the CheckoutController is at the border of the Order module. This is where we handle requests. It is the friendly call to the PurchaseItems class, which lives inside the module, if you will. Now let's look at the interactions this class makes. Well, it talks to the Payment module, but it talks to the Payment module through the

Now let's look at the interactions this class makes. Well, it talks to the payment module, but it talks to the payment module through the createPaymentForOrder abstraction. That is, it doesn't talk to the payment model directly or to PayBuddy directly. Right now, we do have a hard dependency on PayBuddy. We're going to fix it later. But overall, we are deferring a call for this class, which is then responsible for doing everything you need to do within the payment module. Again, it also lives on the border. In the same way, purchaseItems also talk to the product module, again, through a different class.

Again, it also lives on the border. In the same way, purchase items also talk to the Product module, again, through a different class. We use the ProductStockManager to manage stock for the Product model. And we're also passing cartItemCollection, which references a Product, not the Product model itself, but it references a Product through its ID. When it comes to the Order module itself, we use an OrderDTO to represent all the information needed to process an order. Once that's done, we publish an event called OrderFulfilled, which includes the OrderDTO and also the UserDTO. And then we have two listeners that subscribe to the event.

DTO and also the UserDTO. And then we have two listeners that subscribe to the event. The SendOrderConfirmationListener, which is responsible for sending the email to the user, and also the DecreasedProductStockListener, which is responsible for managing the product stock. So at this point, since we have an event being dispatched, and we have listeners subscribing to it, we can actually remove this arrow because it is no longer directly talking to the ProductStockManager. Instead, we are dispatching an event, which might happen in synchronously. And then we have listeners reacting to it.

Instead, we are dispatching an event, which might happen in synchronously. And then we have listeners reacting to it. I also tried to create a few layers here in the diagram. So you can see that Order model, OrderLine model, and sendOrderConfirmation are inside this inner layer. And I use this to denote that they are internal to this module or to this domain, if you will. The same happens with the decreasedProductStock and with the Product model here and the Payment model and PayBuddy right here. So at this point, we have very well defined relationships with all those different modules. And again, I said this in the beginning of the course, and I wanted to reinforce this.

So at this point, we have very well defined relationships with all those different modules. And again, I said this in the beginning of the course, and I wanted to reinforce this. There's no silver bullet when it comes to software engineering. This is not a road that you should follow, but rather ways to increase your toolset and give you options to deal with problems you happen to find when working. In some situations, this might seem overkill. And if it seems overkill, it probably is. Especially if you're working with things like simple credit operations, this is probably not needed. Now, if you're working on an application that has multiple developers working on it, that

not needed. Now, if you're working on an application that has multiple developers working on it, that deals with more complex business rules. This starts to make sense to have the separation between modules and to be careful about how they interact with one another. Even if you do not do that, it's always interesting to be aware of the interactions between different components in your system and how they span across multiple boundaries, which is what we're doing right now. So even if you do not do things this way, exactly the idea of being aware of those boundaries and how different components communicate with one another is very, very important.

So even if you do not do things this way, exactly the idea of being aware of those boundaries and how different components communicate with one another is very, very important. With that said, as you've seen, we've made a lot of changes. We have a fairly stable system. We have very well-defined relationships. And I think this is really good for now. We're going to continue refactoring this on the following lessons and also implement a few other things within our modules, including a payment abstraction. I hope you're enjoying the series and I'll see you in the next video. Bye-bye.

I hope you're enjoying the series and I'll see you in the next video. Bye-bye.