At this point we've got several different files inside of our little test project.
As I've said several times we're going to eventually take the code out of this test project and merge
it into the common module.
Well you might be kind of curious what code is gonna go into the common module and what code we're going
to eventually write inside of one of our services such as the ticket service.
Let's take a look at a quick diagram just to answer that question so inside of our common module we
are going to define our big list of subjects.
So this is going to be all the possible channels that we can emit events to inside of our Nat streaming
server.
We're also going to define our base listener class inside there as well.
We'll also define the interfaces describing all the possible events that we can emit and the data that
is expected for each them we're then going to import these things into each of our different services.
So for example if we eventually have a payment service we're going to import in subjects listener and
say ticket update event and inside the payment service we're going to define our custom listener because
presumably whenever our payment service receives this event or receives this message of ticket created
the payment service is going to want to run some very custom logic the very custom business logic inside
of on message.
So ticket create a listener something like this will be defined inside of one of our services whereas
our list of subjects the base listener class aren't going to be and the ticket created events are all
going to be defined inside the custom or any common library.
The nice thing about this approach is that all of our different services are going to have the exact
same definition of what different subjects there are.
They're all going to share the exact same definition of what events there are and what the structure
of all those events look like they of course are all going to share the same kind of logic around listener.
But what's much more relevant is that they all have the exact same definition of the list of events
and the structure of those events as well.
So this is what is going to really make sure that we do not have some engineer reading the order update
the listener and accidentally trying to emit some kind of order update event with an invalid structure.
It is absolutely critical that all of our different services have the exact same definition of what
subjects are available and the event structure for each of those as well so that's why we're putting
all this stuff inside of our common module.
All right.
So let me answer this question.
Let's take a pause right here.
When we come back the next video we're going to start to do a refactor to our publisher as well.
So right now our publisher is still kind of stuck in the past.
I want to kind of refactor it to have something that looks a little bit more similar to our base listener
and the ticket created listener as well.
So something to just make it a little bit easier to publish some events and make sure that whatever
we are publishing has a valid subject name and some valid data as well.