Let's grade our bottle to represent a ticket.
We're gonna put together a new model file that's gonna be just about identical to all the order stuff
we just wrote out in my model's directory.
I'll make a new file called Ticket dot T.S. at the top.
I will import Mongoose from Mongoose and then we'll create our three interfaces right away.
We'll get an interface of ticket adders and interface of ticket doc which is going to extend Mongoose
dot document and an interface of ticket model which is going to extend longest out model and we'll load
it as a generic ticket doc now.
At this point this is the first time that we are really seeing replication of data between services.
We have already written out code that looks just about identical to this inside of our tickets service.
So you might be curious can we extract this code into our common shared library and then use that inside
of both these services orders and tickets.
The answer is definitely definitely not definitely to want to do it.
What we are writing right here is a implementation or essentially code to save data to the database.
And this could potentially be very specific to the service that we are working in right now.
So we are going to put some attributes inside of here that are just attributes that the order service
alone needs to work correctly.
The only thing that the order service really needs to know about a given ticket is you go backwards
to this diagram the tickets title price and that version thing as well.
Technically also idea I'm just not showing it on this diagram.
There might be a tremendous number of additional pieces of information tied to a ticket that gets saved
inside of the ticket service but the order service doesn't care about all those additional properties
that may or may not exist.
The order service only cares about title Price version and I.T. that's it nothing else.
So we definitely want to have different definitions of what a ticket is between orders and tickets.
Beyond that our order service might eventually grow to encapsulate things that can be ordered or purchased
besides just tickets.
So maybe we can also purchase say parking spot or something like that like a parking pass or something
for some sporting event or what have you.
We would probably want to encapsulate that logic under this order service as well and allow a user to
order a parking pass but a parking pass might have a very different set of attributes than a ticket
so we would not want to essentially lock down the definition of what a ticket is between the order service
and the ticket service.
And that's why we're definitely to make sure that we do not try to share the definition of exactly what
a ticket is.
As it gets saved to the database between these different services.
So that might let's continue on our implementation right here.
So on the ticket we want to have a title price and we're not gonna worry about the version just yet.
No that's has to do with that concurrency stuff.
We're going to come back to that once we have the ability to actually see the concurrency stuff fail.
So right now on it ticket adders we're gonna have only a title that has a string a price that is a number
scenting on our ticket docket right now.
So titled as a string price that is a number and then ticket model.
Once again we're gonna have that method of built
this thing is gonna get some adders that are of type ticket adders and it's going to return a ticket
Doc lets them build out our schema
on the first object inside of here.
Let's list out all the different properties we want to have the persisted to our database.
So we'll put in a title that is of type capital s String.
Don't forget that capital on there.
We definitely want to make sure that this thing is required and then a price there's gonna be a type
of number we'll say this thing is required true and we're going to assume that the price should always
be positive.
Looking gonna put in a minimum price of 0 we do also have to define that to Jason method here as well.
So as the second argument we'll put in another object defined to Jason you are transform receive Doc
and the return value.
And once again let's dump IDI
delete Rhett underscore he looks good.
After that we'll define that build method ticket schema
come on ticket schema.
There we go.
Static stop builds.
Taken a set of attributes which are of type ticket adders and then return a new ticket.
With those adders
I'm getting an air around ticket schema which makes me think I might call the thing just schema up here.
We can stay consistent one way or the other.
I'll change the variable up here to ticket schema
so I've got ticket schema right there consistent with ticket schema right there.
Then after that we will define the actual model so ticket is Mongoose dot model row in the document
type the model type we want to say this in a collection called Ticket throw in the schema as the second
argument.
And then finally we will export
now little gotcha here back inside of order.
We need to import into this order file the definition of what a ticket document is so that all these
interfaces actually work.
So we need to go back to our ticket file that we just put together.
We're going up to the very top where we defined that interface of what a ticket document is.
We'll make sure that we export that so we can import it over into the order so I make sure I get export
right there.
I'm going to say this file will then go backwards in the order model file and at the top let's import
ticket doc from ticket and there we go.
So now I've got the ability to create a ticket.
We can save tickets to the database.
We can load them once we have an instance of a ticket we can assign that ticket to an order either when
it gets created because remember this interface is described in the properties that go into creating
order and we can also assign a ticket to an order instance as well or an order document.
Remember this interface is about an instance of an order.
All right.
So I know at this point time a lot of stuff probably still you know as with many things in this course
probably seems all a bit nasty.
Trust me as soon as we start to write out a little bit more code here and we start to run into issues
specifically around some concurrency stuff and event handling you're gonna start to see it really quickly
on why we've got these two separate models why we are using this kind of population stuff and a lot
of other things are going to start to become clear.
So let's take a pause right here.
Continue chugging on in the next video.