1
00:00:01,390 --> 00:00:07,690
At this point if we do accuse EDL get pods we should successfully be able to see our payment service

2
00:00:07,750 --> 00:00:11,820
up and running to make sure that you see the payment service up and running once as you see that we

3
00:00:11,820 --> 00:00:13,750
are good to go before we move on.

4
00:00:13,750 --> 00:00:18,790
However I do want to also mention that we have not yet installed any modules directly into the payment

5
00:00:18,790 --> 00:00:20,730
service on our local machine.

6
00:00:20,770 --> 00:00:24,230
We have added in some modules or dependencies to be installed inside the pod.

7
00:00:24,260 --> 00:00:28,660
Remember we also have to install them on our local machine so that typescript has access to all the

8
00:00:28,660 --> 00:00:30,520
relevant type definition files.

9
00:00:30,700 --> 00:00:32,620
So I am going to change into that payment directory

10
00:00:36,120 --> 00:00:39,740
and then do an npm install there.

11
00:00:40,130 --> 00:00:40,380
Okay.

12
00:00:40,410 --> 00:00:41,060
Well that is running.

13
00:00:41,070 --> 00:00:45,240
We're gonna go and take a look at a diagram or two just to further understand what the goal of the payment

14
00:00:45,240 --> 00:00:50,040
service is so right now we're going to focus on the different events that we're going to listen for

15
00:00:50,040 --> 00:00:53,300
inside the payment service and the different events we're going to eventually emit.

16
00:00:53,430 --> 00:00:57,540
In particular right now in this video I really wanna think about the different events that we are listening

17
00:00:57,540 --> 00:00:58,530
to.

18
00:00:58,650 --> 00:01:02,810
We definitely need our payment service to understand all the different orders that are created inside

19
00:01:02,810 --> 00:01:06,010
of our app and all the changes that are made to those orders over time.

20
00:01:06,120 --> 00:01:10,150
A user is going to eventually submit requests to try to pay for a very specific order.

21
00:01:10,180 --> 00:01:15,060
So whenever user submits request to pay for an order we need to understand exactly what order they are

22
00:01:15,060 --> 00:01:18,200
trying to pay for and we need to be able to validate that payment.

23
00:01:18,250 --> 00:01:21,090
We have to make sure that is the correct user trying to set the payment.

24
00:01:21,090 --> 00:01:24,590
We have to make sure that the payment is also the correct amount as well.

25
00:01:25,660 --> 00:01:30,280
So we need to think about how we're going to listen for order created and order canceled and the data

26
00:01:30,310 --> 00:01:35,860
that we're going to replicate from those two events into a replicated orders collection inside a payment

27
00:01:35,860 --> 00:01:38,140
service so in total.

28
00:01:38,150 --> 00:01:40,620
Just looking at this diagram I here related to orders.

29
00:01:40,640 --> 00:01:45,340
We definitely need at least two listeners one to listen for order created one to listen for.

30
00:01:45,340 --> 00:01:46,600
Order canceled.

31
00:01:46,720 --> 00:01:52,970
We also need a mongoose model file as well we're gonna first start to work on that order model file

32
00:01:53,050 --> 00:01:58,200
and we're going to define exactly what an order is inside of our payment service before we go and create

33
00:01:58,200 --> 00:01:59,150
that model file.

34
00:01:59,160 --> 00:02:04,350
I won't think about what information or what data we are going to replicate out of these events and

35
00:02:04,350 --> 00:02:06,690
story inside us orders collection.

36
00:02:06,720 --> 00:02:11,920
Let's take a look at a quick diagram okay on the left hand side.

37
00:02:11,920 --> 00:02:16,620
I've got the order created event in all the different properties that are contained inside of it.

38
00:02:16,690 --> 00:02:20,890
So we need to think about all these different properties and decide which of these properties we want

39
00:02:20,890 --> 00:02:24,820
to replicate into the orders collection inside of our payment service.

40
00:02:24,910 --> 00:02:29,610
So we'll go through these one by one the first property is I.T..

41
00:02:29,800 --> 00:02:34,570
Do we need to store the idea of a order that has been created inside of this orders collection the payment

42
00:02:34,570 --> 00:02:35,540
service.

43
00:02:35,560 --> 00:02:37,470
Well yes without a doubt we do.

44
00:02:37,570 --> 00:02:41,890
You might recall that a little bit ago we discussed how it was really important to accurately replicate

45
00:02:41,920 --> 00:02:46,050
ideas for a specific record across different services.

46
00:02:46,090 --> 00:02:51,640
So if we have some ideas for an order inside the payment service that must be the exact same idea as

47
00:02:51,640 --> 00:02:55,120
some order inside the order service they have to have the same idea.

48
00:02:55,180 --> 00:03:01,930
Otherwise we cannot try to find the same record inside both these services All right so next property

49
00:03:02,020 --> 00:03:03,130
status.

50
00:03:03,130 --> 00:03:08,110
Well we probably want to make sure that we saw the status of an order and update over time that we know

51
00:03:08,170 --> 00:03:13,000
when a order can still be paid for and when it gets canceled once an order is canceled we definitely

52
00:03:13,000 --> 00:03:15,750
do not want to accept any payments for it anymore.

53
00:03:15,820 --> 00:03:20,560
So we need our payment service to store the status of an order that it knows whether or not it should

54
00:03:20,560 --> 00:03:25,770
reject a payment.

55
00:03:25,840 --> 00:03:27,750
Next property version.

56
00:03:27,820 --> 00:03:32,890
Well as usual we are using this version flag to make sure that we properly process all different events

57
00:03:32,920 --> 00:03:35,560
across our services in the correct order.

58
00:03:35,570 --> 00:03:36,190
Without a doubt.

59
00:03:36,190 --> 00:03:36,420
Yes.

60
00:03:36,430 --> 00:03:40,930
We want to make sure that we store diversion flag on orders inside our payment service to make sure

61
00:03:40,930 --> 00:03:47,830
that we process all different events related to an order in the correct order.

62
00:03:47,830 --> 00:03:54,540
Next up user I.D. So with user I.D. right here that's going to tell us who create the actual order inside

63
00:03:54,550 --> 00:03:56,670
our payment service whenever a user submits a payment.

64
00:03:56,680 --> 00:04:01,570
We probably want to make sure that that is the user who originally created the order is going to make

65
00:04:01,570 --> 00:04:06,810
sure that one user cannot pay for another user's order though yeah we should probably make sure that

66
00:04:06,810 --> 00:04:11,220
we store the user I.D. so that whenever someone tries to submit a payment we make sure that is the correct

67
00:04:11,220 --> 00:04:15,430
person.

68
00:04:15,430 --> 00:04:20,590
Now how about expires that expires that is going to tell us when a order expires.

69
00:04:20,590 --> 00:04:25,720
And in theory at that point time we should not accept any further payments.

70
00:04:25,720 --> 00:04:30,910
However we're not going to a store expires that expires that is really being used by the expiration

71
00:04:30,910 --> 00:04:36,710
service is the expiration service that decides whether or not a order should be marked as expired.

72
00:04:36,880 --> 00:04:41,500
And in that event that eventually gets emitted the expiration complete event gets processed by the orders

73
00:04:41,560 --> 00:04:42,460
service.

74
00:04:42,460 --> 00:04:48,340
So it's really up to the order service to specifically cancel an order and we should not rely upon the

75
00:04:48,340 --> 00:04:51,580
payment service to decide whether or not an order is still valid.

76
00:04:51,580 --> 00:04:56,920
So we are not going to store the expires at flag instead to decide whether or not an order is still

77
00:04:56,920 --> 00:04:58,380
valid and can be paid for it.

78
00:04:58,420 --> 00:05:00,640
We're going to use the status property right here.

79
00:05:00,640 --> 00:05:03,130
That was the original gold at status property status.

80
00:05:03,130 --> 00:05:09,490
Property was going to tell us what status and order was in then finally we've got some information about

81
00:05:09,490 --> 00:05:15,450
the ticket do we want to store the idea that ticket or the price will for the payment service.

82
00:05:15,450 --> 00:05:18,500
We probably don't really care about the idea the ticket at all.

83
00:05:18,600 --> 00:05:23,100
It doesn't really make a difference what ticket we are paying for all that really matters is that well

84
00:05:23,220 --> 00:05:28,860
we are paying for some specific amount don't really care about any information tied to the ticket around

85
00:05:28,860 --> 00:05:31,130
its I.D. or its title or anything like that.

86
00:05:31,140 --> 00:05:35,100
The only thing we really care about is the price that because that is going to tell us exactly how much

87
00:05:35,100 --> 00:05:37,070
an incoming payment should be for.

88
00:05:37,080 --> 00:05:42,330
So we will just take out the price property and store it along with our order.

89
00:05:42,510 --> 00:05:42,900
That's it.

90
00:05:42,900 --> 00:05:46,740
That's what the replicated information that we're going to store around and order inside of our payment

91
00:05:46,740 --> 00:05:50,950
service I.D. status version user I.D. price DNA.

92
00:05:50,970 --> 00:05:56,100
We've got these properties put together plans right here and we'll put together our order model file

93
00:05:56,160 --> 00:05:56,880
in the next video.