Now that you've seen the goal of this application we're going to spend a couple of videos to go over
the design of this app.
We're going to first begin by discussing the different pieces of data that we're going to have to store
in order to implement this thing.
So in total I think we are going to have four different types of resources.
We're going to first have some table or collection some storage of users as you guessed this is going
to store all the different users who sign up to our application and presumably along with each user
We'll store their email and password.
That's pretty much it for each user will then have some collection or table of tickets and each of these
records are going to represent one single ticket that someone is trying to buy or sell for every ticket.
We're going to allow it to have a title that's gonna be a string a price which will be a number a user
I.D. reference which is going to be a reference to the user who is trying to sell the ticket and a reference
to some order.
Let's give you our order I.D. and that order I.D. reference is going to be the kind of purchase attempt
to actually get at this ticket or they're going to have a collection or table of orders.
So for each order that gets created we're going to store the user I.D. of the person who is creating
this Order the status of the order.
So whether it is canceled whether we are waiting for payment to come in whether it is 100 percent complete
and some new person owns the ticket we're going to store the ticket I.D. and the time at which the order
expires.
Because remember people only have 15 minutes or so or some configurable amount of time to actually purchase
a ticket.
Just be really clear.
This order represents the attempt to purchase a ticket so the instant that a user clicks on that purchase
button right there we're going to create this order object in the order object represents the intent
to purchase the ticket that expires that will represent the 15 minutes.
And as soon as the person actually enters in their credit card or what have you we will update the order
status to complete it or awaiting payment or something like that.
And then finally we're going to have a charge object.
This charge is going to represent our ability to actually charge some person's credit card and get some
money out of them so on the charge object will have a reference to the order that a user is trying to
pay for the status of the charge.
So whether it is created failed or completed the amount of money tied to the charge and we also have
too little maintenance fields or kind of administrative fields on here as well.
Ones could be a stripe I.D..
Again we're going to be using stripe to handle payments stripe I.D. is going to be a reference to some
object over in the stripe J.S. or the stripe world.
There's going to be us trying to actually Bill someone's credit card.
We're also going to the ability to refund tickets as well.
So we're going to have something called the stripe refund idea on here too at this point.
I'm sure a lot of these different objects look completely foreign.
You might be saying what is the difference between a ticket and an order.
What's the difference between ordering and charge.
Don't worry over time you're going to see the purpose of each of these different objects.
Right now I just want to get these pieces of terminology out there and get you thinking about them.
Yes that's little design talk.
Number one we're going to go through another couple of videos just like these to give you some big overall
picture.
Give you an idea of how we're going to put this thing together so quick pause.
Next one in just a moment.