1 00:00:01,860 --> 00:00:05,350 At this point we've got several different files inside of our little test project. 2 00:00:05,430 --> 00:00:09,450 As I've said several times we're going to eventually take the code out of this test project and merge 3 00:00:09,450 --> 00:00:10,980 it into the common module. 4 00:00:10,980 --> 00:00:15,390 Well you might be kind of curious what code is gonna go into the common module and what code we're going 5 00:00:15,390 --> 00:00:19,290 to eventually write inside of one of our services such as the ticket service. 6 00:00:19,290 --> 00:00:24,260 Let's take a look at a quick diagram just to answer that question so inside of our common module we 7 00:00:24,260 --> 00:00:27,030 are going to define our big list of subjects. 8 00:00:27,030 --> 00:00:31,740 So this is going to be all the possible channels that we can emit events to inside of our Nat streaming 9 00:00:31,740 --> 00:00:32,880 server. 10 00:00:32,880 --> 00:00:37,620 We're also going to define our base listener class inside there as well. 11 00:00:37,830 --> 00:00:42,840 We'll also define the interfaces describing all the possible events that we can emit and the data that 12 00:00:42,840 --> 00:00:50,270 is expected for each them we're then going to import these things into each of our different services. 13 00:00:50,290 --> 00:00:57,010 So for example if we eventually have a payment service we're going to import in subjects listener and 14 00:00:57,010 --> 00:01:03,190 say ticket update event and inside the payment service we're going to define our custom listener because 15 00:01:03,190 --> 00:01:08,770 presumably whenever our payment service receives this event or receives this message of ticket created 16 00:01:09,100 --> 00:01:14,650 the payment service is going to want to run some very custom logic the very custom business logic inside 17 00:01:14,650 --> 00:01:16,050 of on message. 18 00:01:16,050 --> 00:01:20,560 So ticket create a listener something like this will be defined inside of one of our services whereas 19 00:01:20,590 --> 00:01:27,130 our list of subjects the base listener class aren't going to be and the ticket created events are all 20 00:01:27,130 --> 00:01:30,430 going to be defined inside the custom or any common library. 21 00:01:31,630 --> 00:01:35,560 The nice thing about this approach is that all of our different services are going to have the exact 22 00:01:35,560 --> 00:01:39,150 same definition of what different subjects there are. 23 00:01:39,280 --> 00:01:43,870 They're all going to share the exact same definition of what events there are and what the structure 24 00:01:43,870 --> 00:01:49,290 of all those events look like they of course are all going to share the same kind of logic around listener. 25 00:01:49,290 --> 00:01:53,460 But what's much more relevant is that they all have the exact same definition of the list of events 26 00:01:53,910 --> 00:01:56,450 and the structure of those events as well. 27 00:01:56,490 --> 00:02:01,650 So this is what is going to really make sure that we do not have some engineer reading the order update 28 00:02:01,650 --> 00:02:07,520 the listener and accidentally trying to emit some kind of order update event with an invalid structure. 29 00:02:07,590 --> 00:02:12,570 It is absolutely critical that all of our different services have the exact same definition of what 30 00:02:12,570 --> 00:02:18,710 subjects are available and the event structure for each of those as well so that's why we're putting 31 00:02:18,710 --> 00:02:21,750 all this stuff inside of our common module. 32 00:02:21,750 --> 00:02:22,010 All right. 33 00:02:22,020 --> 00:02:23,440 So let me answer this question. 34 00:02:23,520 --> 00:02:24,480 Let's take a pause right here. 35 00:02:24,480 --> 00:02:29,000 When we come back the next video we're going to start to do a refactor to our publisher as well. 36 00:02:29,010 --> 00:02:32,170 So right now our publisher is still kind of stuck in the past. 37 00:02:32,190 --> 00:02:37,440 I want to kind of refactor it to have something that looks a little bit more similar to our base listener 38 00:02:37,530 --> 00:02:39,930 and the ticket created listener as well. 39 00:02:39,930 --> 00:02:44,610 So something to just make it a little bit easier to publish some events and make sure that whatever 40 00:02:44,610 --> 00:02:48,740 we are publishing has a valid subject name and some valid data as well.