Okay, so now we've successfully set up our payment system in the previous section so we can make that
payment from client browser to stripe.
But we need to think about what's going to happen on our API side.
Because at the moment we don't have an order being created on our API, so nobody's going to deliver
the fake products that they have ordered.
And we need to deal with that in this section.
So we're going to start looking at orders.
And when somebody makes a payment, then we need to create the corresponding order in our API server.
So let's go take a look at doing that.
And we're going to start with creating some entities for this.
Now our order is going to be a combination of several things.
Really.
It's going to be the order itself that's going to have details about the order items.
We're also going to need to track the shipping address.
Possibly we want to store the payment summary, the card that was used, not the full card, just the
last four digits, the expiry date and the brand similar to what we displayed in the payment review
and would also need things like an order status as well.
So we have several different elements that make up the order.
And the common practice is to create a new folder for something like this and we'll call it order aggregate,
an aggregate of everything that makes up an order.
And inside our new order aggregate folder we'll create a new file and I'll call this one just in fact
I'll call it shipping address.
Just to be very clear, it's not the same as the other address that we're storing with the user information
effectively.
And that needs to be a class.
So I need to select class and then I can use shipping address.
Now this is going to be very similar to the address entity but with one crucial difference in that we're
not going to store the ID with the address.
It's going to be part of the order.
And what we refer to this as is an owned entity, because it's going to be part of the order table,
but it is a separate entity in itself.
And I'll demonstrate what I mean by that very soon.
So the properties for this address, I'm just going to copy everything apart from the ID, and I'm going
to go to the shipping address and paste in those properties inside here and just do a bit of reformatting.
And we need the JSON property name to stay as postal code as well.
So I'll just bring in system text JSON serialization to handle that.
Now we're going to use something that's referred to in here as an owned property.
And we do that by giving this an attribute as owned.
And this shipping address will not have its own table in our database, but it's going to be in line
with an order.
So this is going to make more sense when we see it in action.
But for now, an owned property doesn't need an ID and we use the owned attribute inside here.
The next thing we'll add in our order aggregate folder, we'll create another new file and we'll create
another class.
And we'll call this one product item ordered.
And inside here we will have a prop that's an int and we'll call it product ID.
We'll have a prop that's a string.
And this will be for the name of the product.
And we'll have a prop that's a string of the picture you URL.
And we'll make the name and picture URL required as well.
This is going to be another owned property.
So our orders are going to have a one to many relationship with an order item that we have yet to create.
And inside that order item we're going to track the product item ordered.
And this is really just a historical snapshot of the item that they ordered when they made this particular
order.
So the name could change slightly Or the picture URL could be updated to something else, but we'll
keep the original picture URL that was provided when the user made that order.
And once again, even though we do technically have an ID here, we're going to make this an owned property
as well.
And this is going to be owned by the order item.
Another thing that we'll have inside our order aggregates is the order status.
So I'm going to create another new file.
And this one's going to be an enum type.
And we'll call this order status.
And inside here we're going to have various statuses.
So we'll have a pending status for whilst we're waiting for payment for this order we'll have a payment
received and we'll have a payment failed.
And we may come back and add more statuses as we need them.
But we won't have things like shipped because we're not really going to implement some kind of delivery
system where a fake delivery driver comes up and picks up our fake orders from the fake warehouse that
we simply don't have.
We're not going to go that far.
Of course, that would be silly.
So we'll just stick with these for now, and we'll come back and add more if we need to.
And the next one we'll create will create an order item.
So this is going to be a class.
And we'll say order item.
And inside this class we'll have a prop that's an int that's called ID.
We'll have a prop that's going to be the product item ordered.
And we'll just call this item ordered and we'll make this required.
We don't want an order item without the product item ordered.
We'll have a prop that's going to be a long for the price.
And we'll also have the prop that's an int for the quantity.
And we'll add another class inside our order.
Aggregate another new file.
And this is going to be a class and we'll call it payment summary.
Inside this class we will have a prop that's an int for the last four of the cards.
We'll have a prop that's a string for the brand, a prop that's an int for the experiment for the expiry
month, and a prop that's an int for the exp year.
And we'll make the brand required.
And we'll also make this an owned property.
And it's going to be an owned property by the order.
So we'll make this owned as well.
So these are all of the different elements that are going to make up our order aggregate without the
actual order itself.
And because we've got quite a few classes to create in this section, I'll split this into two parts.
And next we'll take a look at creating the order entity itself.