1
00:00:00,090 --> 00:00:01,640
Welcome to the Architecture 
Corner. 

2
00:00:01,650 --> 00:00:05,620
Today we're taking a deep dive 
into something that can truly 

3
00:00:05,630 --> 00:00:09,280
transform how you manage complex
systems, the advanced 

4
00:00:09,290 --> 00:00:12,400
capabilities of Event Catalog. 
We've touched on the basics 

5
00:00:12,410 --> 00:00:16,470
before, but these features, they
offer huge value, especially 

6
00:00:16,480 --> 00:00:19,820
when you're dealing with larger,
more integrated systems. 

7
00:00:19,890 --> 00:00:22,770
Yeah, it's fascinating actually,
how these advanced features 

8
00:00:22,990 --> 00:00:26,660
tackle the real world messiness 
of, you know, scaling and 

9
00:00:26,720 --> 00:00:29,660
evolving systems. 
They make your documentation 

10
00:00:29,730 --> 00:00:33,030
more than just a record, becomes
an active tool guiding 

11
00:00:33,040 --> 00:00:35,830
development and frankly, 
preventing chaos. 

12
00:00:35,940 --> 00:00:38,450
Absolutely. 
So OK, let's unpack this. 

13
00:00:38,520 --> 00:00:41,230
Let's see how event catalog 
helps you level up from just 

14
00:00:41,240 --> 00:00:44,210
managing events to really 
mastering that whole event 

15
00:00:44,220 --> 00:00:46,550
driven landscape. 
Now when your system grows, one 

16
00:00:46,560 --> 00:00:49,050
of the biggest headaches is 
keeping boundaries clear, right?

17
00:00:49,160 --> 00:00:51,770
That's where event catalogs 
ability to capture sub domains 

18
00:00:51,780 --> 00:00:54,730
becomes, well, game changer. 
And this isn't just some random 

19
00:00:54,740 --> 00:00:56,230
grouping. 
It lets you do soft 

20
00:00:56,240 --> 00:00:59,290
segmentation, clearly mark 
boundaries around services 

21
00:00:59,300 --> 00:01:01,800
within a domain. 
It follows domain have been 

22
00:01:01,810 --> 00:01:04,980
designed DDD concepts and 
crucially this empowers 

23
00:01:04,989 --> 00:01:07,340
individual teams. 
They can evolve their own 

24
00:01:07,350 --> 00:01:10,220
services independently. 
Real domain ownership. 

25
00:01:10,230 --> 00:01:12,260
Right. 
And defining those subdomains is

26
00:01:12,270 --> 00:01:15,100
just vital for clarity, for 
manageability. 

27
00:01:15,110 --> 00:01:18,060
It stops your whole event 
ecosystem looking like one giant

28
00:01:18,070 --> 00:01:21,580
confusing BLOB. 
It lets teams own their patch, 

29
00:01:21,630 --> 00:01:24,270
iterate, you know, without 
stepping on everyone else's 

30
00:01:24,280 --> 00:01:25,940
toes. 
OK, but systems are always 

31
00:01:25,950 --> 00:01:29,300
changing, aren't they? 
Stuff evolves, So how do we 

32
00:01:29,350 --> 00:01:30,940
manage that? 
How do we make sure everyone 

33
00:01:30,950 --> 00:01:33,200
knows what's current That's not?
Good question. 

34
00:01:33,290 --> 00:01:36,640
Event Catalog has some key tools
for this constant flux 

35
00:01:36,850 --> 00:01:39,470
versioning, change logs and 
deprecating elements. 

36
00:01:39,510 --> 00:01:42,460
Ah, OK, tell us about those. 
So versioning. 

37
00:01:42,510 --> 00:01:46,620
It's optional but really 
powerful for tracking how 

38
00:01:46,630 --> 00:01:48,880
services and messages evolve 
over time. 

39
00:01:48,970 --> 00:01:51,300
It means you can keep old 
versions around, mark them 

40
00:01:51,310 --> 00:01:54,260
clearly, you get historical 
context, smoother transitions, 

41
00:01:54,630 --> 00:01:56,800
then change logs. 
These are pretty essential I'd 

42
00:01:56,810 --> 00:01:58,320
say. 
They capture the what changed 

43
00:01:58,330 --> 00:02:01,720
for domain services messages and
they could be really rich, you 

44
00:02:01,730 --> 00:02:04,190
know even support diff sometimes
showing exactly what was 

45
00:02:04,200 --> 00:02:06,400
modified. 
Nice and deprecating. 

46
00:02:06,470 --> 00:02:09,660
Right, deprecating elements for 
things reaching end of life. 

47
00:02:09,729 --> 00:02:12,820
It gives you a clear way to flag
services, commands, events, 

48
00:02:12,830 --> 00:02:16,100
whatever as deprecated. 
You can even add dates and event

49
00:02:16,110 --> 00:02:19,860
catalog uses clear visual cues 
like read if the deprecation 

50
00:02:19,870 --> 00:02:21,900
dates passed, yellow if it's 
coming up. 

51
00:02:21,970 --> 00:02:25,320
Users see it immediately. 
OK, so those tools help manage 

52
00:02:25,330 --> 00:02:27,600
the individual pieces and their 
changes. 

53
00:02:27,810 --> 00:02:29,280
But what about the bigger 
picture? 

54
00:02:29,350 --> 00:02:32,120
Understanding how everything 
connects and interacts, 

55
00:02:32,340 --> 00:02:36,690
Visualizing the flow? 
That seems critical too. 

56
00:02:36,700 --> 00:02:38,880
Well, Event Catalog helps there 
with channels. 

57
00:02:38,950 --> 00:02:40,620
These capture the actual 
mechanics. 

58
00:02:40,630 --> 00:02:43,840
Then Kafka topics, AWSQSQS, that
sort of thing. 

59
00:02:43,930 --> 00:02:47,350
They clearly show the links 
between producers and consumers.

60
00:02:47,400 --> 00:02:50,300
It's like having a live plumbing
diagram for your event 

61
00:02:50,310 --> 00:02:52,000
architecture. 
Yeah, exactly. 

62
00:02:52,090 --> 00:02:55,210
And if you need to visualize a 
whole end to end process, one 

63
00:02:55,220 --> 00:02:58,000
that crosses multiple services, 
Flows offered a pretty 

64
00:02:58,010 --> 00:03:00,900
interesting way to do that. 
It's text based, kind of a mix 

65
00:03:00,910 --> 00:03:04,650
between say BPMN for business 
processes and event storming. 

66
00:03:04,720 --> 00:03:07,400
It focuses specifically on the 
services involved and the 

67
00:03:07,410 --> 00:03:09,310
messages they exchanged during a
process. 

68
00:03:09,320 --> 00:03:13,510
And for people like me who love 
a good diagram, you can embed 

69
00:03:13,520 --> 00:03:16,470
tools like Mermaid and plant UML
directly in the docs. 

70
00:03:16,960 --> 00:03:19,470
That avoids all that manual 
exporting and uploading. 

71
00:03:19,560 --> 00:03:21,170
Pretty neat. 
Definitely saves a lot of 

72
00:03:21,180 --> 00:03:23,670
hassle. 
But how do you make sure all 

73
00:03:23,680 --> 00:03:30,090
this great documentation stays, 
you know, consistent, complete, 

74
00:03:30,140 --> 00:03:32,310
accurate as things keep 
changing? 

75
00:03:32,360 --> 00:03:34,210
Ah yeah, the $1,000,000 
question. 

76
00:03:34,460 --> 00:03:36,530
That's where governance reports 
kick in. 

77
00:03:36,660 --> 00:03:39,530
They essentially give you a 
health status for your 

78
00:03:39,540 --> 00:03:42,810
documentation based on criteria.
Like is it complete as it 

79
00:03:42,820 --> 00:03:44,750
follows standards? 
Is ownership clear? 

80
00:03:44,800 --> 00:03:46,990
Is the life cycle managed 
properly? 

81
00:03:47,120 --> 00:03:50,090
And the cool part is you can 
integrate these reports into 

82
00:03:50,100 --> 00:03:53,250
your CI CD pipelines so 
documentation stops being an 

83
00:03:53,260 --> 00:03:57,320
afterthought and becomes like a 
proactive quality gate right in 

84
00:03:57,330 --> 00:04:00,180
your delivery process. 
Embedding quality checks makes 

85
00:04:00,190 --> 00:04:01,790
sense. 
So with all this potential 

86
00:04:01,800 --> 00:04:04,670
documentation, how do bigger 
organizations manage it all? 

87
00:04:04,680 --> 00:04:06,330
Keep it organized. 
Good point. 

88
00:04:06,380 --> 00:04:08,700
Event Catalog supports different
deployment strategies. 

89
00:04:08,710 --> 00:04:11,410
You could have one central 
repository, or you could keep 

90
00:04:11,420 --> 00:04:14,490
documentation right next to the 
code in each services repo. 

91
00:04:14,560 --> 00:04:18,010
But for really large orgs, 
Federation is a key advanced 

92
00:04:18,019 --> 00:04:19,930
feature. 
It lets you stitch together 

93
00:04:19,940 --> 00:04:23,630
documentation from lots of 
different repositories into one 

94
00:04:23,640 --> 00:04:27,460
single unified view. 
What's really powerful is how it

95
00:04:27,470 --> 00:04:31,120
handles resolving dependencies 
across those different 

96
00:04:31,130 --> 00:04:34,660
documentation sets across teams 
seamlessly. 

97
00:04:34,670 --> 00:04:38,080
Wow, you have massively speeds 
up team independence and large 

98
00:04:38,090 --> 00:04:40,340
scale integration. 
Otherwise you're stuck mocking 

99
00:04:40,350 --> 00:04:42,900
events locally from other teams,
which can be a pain. 

100
00:04:43,350 --> 00:04:47,340
OK, this all sounds incredibly 
powerful, but I can imagine a 

101
00:04:47,350 --> 00:04:50,500
smaller team maybe just starting
out with EDTA thinking, wow, is 

102
00:04:50,510 --> 00:04:53,660
this maybe too much? 
Too much documentation overhead?

103
00:04:53,730 --> 00:04:56,480
How do you strike that balance? 
That's a really fair question. 

104
00:04:56,570 --> 00:04:59,630
Look, while these features offer
immense capability, my advice is

105
00:04:59,640 --> 00:05:02,810
always start small, Test the 
water, see what value specific 

106
00:05:02,820 --> 00:05:05,810
features bring to your context, 
your needs, the actual syntax 

107
00:05:05,820 --> 00:05:07,690
for event catalog. 
You can pick that up very 

108
00:05:07,700 --> 00:05:08,970
quickly. 
That's probably not going to be 

109
00:05:08,980 --> 00:05:11,350
your biggest hurdle. 
The real challenge is finding 

110
00:05:11,360 --> 00:05:14,270
that sweet spot for your team, 
your organization, using these 

111
00:05:14,280 --> 00:05:16,900
tools effectively without, you 
know, over engineering the whole

112
00:05:16,910 --> 00:05:18,110
thing. 
Sound advice? 

113
00:05:18,160 --> 00:05:21,610
Start small, find the value. 
And that brings us towards the 

114
00:05:21,620 --> 00:05:24,570
end of our deep dive into the 
advanced capabilities of Event 

115
00:05:24,580 --> 00:05:26,400
Catalog. 
So maybe something to think 

116
00:05:26,410 --> 00:05:30,660
about is this, how might 
embedding those quality checks, 

117
00:05:30,670 --> 00:05:33,100
those governance reports 
directly into your delivery 

118
00:05:33,110 --> 00:05:36,820
pipeline instead of relying on 
manual reviews later, how might 

119
00:05:36,830 --> 00:05:39,680
that transform your team's 
efficiency and maybe even their 

120
00:05:39,690 --> 00:05:42,120
confidence when building event 
driven systems? 

121
00:05:42,330 --> 00:05:44,400
Interesting thought. 
We've been exploring insights 

122
00:05:44,410 --> 00:05:46,680
inspired by Mario Bettencourt's 
work today. 

123
00:05:46,790 --> 00:05:48,780
For more detailed information, 
definitely check out the 

124
00:05:48,790 --> 00:05:50,640
description. 
And remember to subscribe for 

125
00:05:50,650 --> 00:05:53,000
free to the Architecture Corner 
newsletter over at 

126
00:05:53,010 --> 00:05:56,140
architecturecorner.substack.com.
Thanks for joining us.