At this point if we do accuse EDL get pods we should successfully be able to see our payment service
up and running to make sure that you see the payment service up and running once as you see that we
are good to go before we move on.
However I do want to also mention that we have not yet installed any modules directly into the payment
service on our local machine.
We have added in some modules or dependencies to be installed inside the pod.
Remember we also have to install them on our local machine so that typescript has access to all the
relevant type definition files.
So I am going to change into that payment directory
and then do an npm install there.
Okay.
Well that is running.
We're gonna go and take a look at a diagram or two just to further understand what the goal of the payment
service is so right now we're going to focus on the different events that we're going to listen for
inside the payment service and the different events we're going to eventually emit.
In particular right now in this video I really wanna think about the different events that we are listening
to.
We definitely need our payment service to understand all the different orders that are created inside
of our app and all the changes that are made to those orders over time.
A user is going to eventually submit requests to try to pay for a very specific order.
So whenever user submits request to pay for an order we need to understand exactly what order they are
trying to pay for and we need to be able to validate that payment.
We have to make sure that is the correct user trying to set the payment.
We have to make sure that the payment is also the correct amount as well.
So we need to think about how we're going to listen for order created and order canceled and the data
that we're going to replicate from those two events into a replicated orders collection inside a payment
service so in total.
Just looking at this diagram I here related to orders.
We definitely need at least two listeners one to listen for order created one to listen for.
Order canceled.
We also need a mongoose model file as well we're gonna first start to work on that order model file
and we're going to define exactly what an order is inside of our payment service before we go and create
that model file.
I won't think about what information or what data we are going to replicate out of these events and
story inside us orders collection.
Let's take a look at a quick diagram okay on the left hand side.
I've got the order created event in all the different properties that are contained inside of it.
So we need to think about all these different properties and decide which of these properties we want
to replicate into the orders collection inside of our payment service.
So we'll go through these one by one the first property is I.T..
Do we need to store the idea of a order that has been created inside of this orders collection the payment
service.
Well yes without a doubt we do.
You might recall that a little bit ago we discussed how it was really important to accurately replicate
ideas for a specific record across different services.
So if we have some ideas for an order inside the payment service that must be the exact same idea as
some order inside the order service they have to have the same idea.
Otherwise we cannot try to find the same record inside both these services All right so next property
status.
Well we probably want to make sure that we saw the status of an order and update over time that we know
when a order can still be paid for and when it gets canceled once an order is canceled we definitely
do not want to accept any payments for it anymore.
So we need our payment service to store the status of an order that it knows whether or not it should
reject a payment.
Next property version.
Well as usual we are using this version flag to make sure that we properly process all different events
across our services in the correct order.
Without a doubt.
Yes.
We want to make sure that we store diversion flag on orders inside our payment service to make sure
that we process all different events related to an order in the correct order.
Next up user I.D. So with user I.D. right here that's going to tell us who create the actual order inside
our payment service whenever a user submits a payment.
We probably want to make sure that that is the user who originally created the order is going to make
sure that one user cannot pay for another user's order though yeah we should probably make sure that
we store the user I.D. so that whenever someone tries to submit a payment we make sure that is the correct
person.
Now how about expires that expires that is going to tell us when a order expires.
And in theory at that point time we should not accept any further payments.
However we're not going to a store expires that expires that is really being used by the expiration
service is the expiration service that decides whether or not a order should be marked as expired.
And in that event that eventually gets emitted the expiration complete event gets processed by the orders
service.
So it's really up to the order service to specifically cancel an order and we should not rely upon the
payment service to decide whether or not an order is still valid.
So we are not going to store the expires at flag instead to decide whether or not an order is still
valid and can be paid for it.
We're going to use the status property right here.
That was the original gold at status property status.
Property was going to tell us what status and order was in then finally we've got some information about
the ticket do we want to store the idea that ticket or the price will for the payment service.
We probably don't really care about the idea the ticket at all.
It doesn't really make a difference what ticket we are paying for all that really matters is that well
we are paying for some specific amount don't really care about any information tied to the ticket around
its I.D. or its title or anything like that.
The only thing we really care about is the price that because that is going to tell us exactly how much
an incoming payment should be for.
So we will just take out the price property and store it along with our order.
That's it.
That's what the replicated information that we're going to store around and order inside of our payment
service I.D. status version user I.D. price DNA.
We've got these properties put together plans right here and we'll put together our order model file
in the next video.