1
00:00:01,080 --> 00:00:04,870
We've got our full list of root handlers put together inside of our order service.

2
00:00:04,910 --> 00:00:09,120
So we're now going to start to think about adding in support for events to this thing as well.

3
00:00:09,120 --> 00:00:12,330
In total our order service is going to be met two kinds of events.

4
00:00:12,420 --> 00:00:17,160
You might remember that we still have that EDF from a couple of videos ago when we were originally talking

5
00:00:17,160 --> 00:00:17,920
about Nats.

6
00:00:18,000 --> 00:00:22,650
This PDA listed out all the different events we're going to eventually publish and we had said that

7
00:00:22,650 --> 00:00:29,380
the order service was going to publish events of order created and order canceled please take a look

8
00:00:29,650 --> 00:00:33,910
at the reason that we are implementing both those events.

9
00:00:33,930 --> 00:00:35,960
First off is order it created.

10
00:00:36,030 --> 00:00:41,370
The goal of order created is to tell every other service that well in order has just been created.

11
00:00:41,580 --> 00:00:45,900
Let's take a look at why each of these different services needs to know about this order being created

12
00:00:46,140 --> 00:00:50,850
because it turns out that on this event we're going to have to commit a very particular piece of data

13
00:00:52,100 --> 00:00:56,870
we'll start off first at the payment service the payment service needs to know that there's going to

14
00:00:56,870 --> 00:01:02,330
be some kind of new order and that some user might attempt to submit some payment in the form of a credit

15
00:01:02,330 --> 00:01:04,120
card or something like that.

16
00:01:04,250 --> 00:01:08,960
It's a payment service needs to know about order created for two very important reasons.

17
00:01:08,960 --> 00:01:14,930
First it needs to know just that there is an order that needs to be paid because eventually when a user

18
00:01:14,930 --> 00:01:19,730
tries to submit that credit card they're going to also include the I.D. of the order that they are trying

19
00:01:19,730 --> 00:01:20,630
to pay for.

20
00:01:20,850 --> 00:01:25,880
The payments just service just needs to know hey here's some I.D. of an order and I should receive payment

21
00:01:25,880 --> 00:01:26,380
for this.

22
00:01:27,050 --> 00:01:32,880
But the payment service also needs to know very critically how much that order costs.

23
00:01:33,020 --> 00:01:36,680
So it needs to know that it's going to receive a payment for some amount of money.

24
00:01:37,470 --> 00:01:42,180
The order service or the order itself doesn't actually know about how much the order costs.

25
00:01:42,180 --> 00:01:47,370
Instead it is the embedded ticket that is inside the order that is going to tell us how much the order

26
00:01:47,430 --> 00:01:49,550
needs to be paid for.

27
00:01:49,620 --> 00:01:54,150
That's why we are communicating this information with the payment service order created is also going

28
00:01:54,150 --> 00:01:58,230
to go over to the expiration service so we can start up that 15 minute timer.

29
00:01:58,230 --> 00:02:01,040
Now remember it's not necessarily 15 minutes per say.

30
00:02:01,080 --> 00:02:07,730
Instead the order itself has an expiration time all ready marked on its got that expires at Flag.

31
00:02:07,770 --> 00:02:12,360
So we just need to make sure that order created communicates that expiration time over to the expiration

32
00:02:12,360 --> 00:02:13,110
service.

33
00:02:13,200 --> 00:02:17,460
So the expiration service can eventually say after 15 minutes or however long it is.

34
00:02:17,490 --> 00:02:19,670
This order should now be expired.

35
00:02:19,860 --> 00:02:22,300
And then finally and this one's a little bit confusing.

36
00:02:22,440 --> 00:02:26,330
The ticket service also needs to know when an order has been created.

37
00:02:26,770 --> 00:02:33,550
And the reason for that is that the ticket service needs to somehow lock down a ticket and prevent editing.

38
00:02:33,570 --> 00:02:39,420
So imagine the case in which an ordered go ask me a user goes to purchase a ticket when the ticket cost

39
00:02:39,420 --> 00:02:45,090
twenty dollars and then maybe right after the user creates the order maybe you say two minutes after

40
00:02:45,780 --> 00:02:50,130
the person who is selling the ticket goes to the ticket service and adjust the price of that ticket

41
00:02:50,160 --> 00:02:52,300
to two thousand dollars.

42
00:02:52,320 --> 00:02:54,560
We definitely want to prevent that from happening.

43
00:02:54,630 --> 00:02:59,280
So once an order has been created and a ticket has been reserved we need to somehow make sure that a

44
00:02:59,280 --> 00:03:05,320
ticket can not be edited so we're gonna do so by making sure that this order created event goes over

45
00:03:05,320 --> 00:03:10,690
to the ticket service the ticket service is going to accept that event that's going to somehow lock

46
00:03:10,690 --> 00:03:16,970
down a ticket from further editing until eventually the order is either paid for or cancelled that's

47
00:03:16,970 --> 00:03:22,220
it for order created the other event that this thing is going to emit is order canceled.

48
00:03:22,370 --> 00:03:23,720
And this one's a little bit more predictable.

49
00:03:23,740 --> 00:03:24,800
So order canceled.

50
00:03:24,940 --> 00:03:30,160
That's pretty much going to unreserved a ticket from the ticket service which means that the ticket

51
00:03:30,160 --> 00:03:34,450
can be edited again and the person who owns the ticket can change the price of the title or whatever

52
00:03:34,450 --> 00:03:38,710
else order cancel is also going to go over to the payment service.

53
00:03:38,710 --> 00:03:43,090
This is just to tell the payment service that it should reject any further payments that are made for

54
00:03:43,090 --> 00:03:43,930
this order.

55
00:03:43,930 --> 00:03:46,900
And technically this is also going to handle refunds as well.

56
00:03:46,900 --> 00:03:50,420
You'll see example that later on OK.

57
00:03:50,430 --> 00:03:51,200
So that might.

58
00:03:51,240 --> 00:03:55,590
Those are the two events we're going to eventually emit from the order service.

59
00:03:55,800 --> 00:04:00,330
Now back inside of our Ed I just want to give you a really quick reminder on how we create events in

60
00:04:00,330 --> 00:04:02,820
general inside of our common module.

61
00:04:02,850 --> 00:04:09,360
We've got that S.R. C events directory so inside of here we are creating different files and these files

62
00:04:09,420 --> 00:04:15,750
contain exported interfaces that describe these subjects and the data that is contained within any given

63
00:04:15,750 --> 00:04:16,120
event.

64
00:04:16,800 --> 00:04:22,970
So in order to implement Order cancelled and order created we pretty much just have to create two new

65
00:04:22,970 --> 00:04:24,720
files inside that events directory.

66
00:04:24,860 --> 00:04:29,120
Great interfaces inside them that described these subjects and the data that is going to be contained

67
00:04:29,210 --> 00:04:34,730
on each of these events export them and then republish our common module and update the common module

68
00:04:34,730 --> 00:04:36,880
version inside of our order service.

69
00:04:36,950 --> 00:04:38,990
That's pretty much it.

70
00:04:39,040 --> 00:04:42,720
So that means we'll take a pause right here and start to build out these events in just a moment.