Modularizing the Monolith - Jimmy Bogard

Modularizing the Monolith - Jimmy Bogard - NDC Oslo 2024

Рет қаралды 18,350

NDC Conferences

Күн бұрын

Пікірлер: 30

@kedzior-io 2 ай бұрын

I have been writing all my software like this for the past 6 years, never needed any other way. Fantastic talk.

@theanswer_19 Ай бұрын

How big is the team modifying the code ? Wondering how, let's say 10 modules live together and evolve over time. Will some get orphaned ? Will deployment be a bottleneck with multiple teams owning this monolith?

@TechTalksWeekly 3 ай бұрын

This is a fantastic talk and it has been featured in the last issue of Tech Talks Weekly newsletter 🎉 Congrats!

@brynyard 3 ай бұрын

Somebody seriously needs to make a talk why _not_ just turn everything into completely independent modules. Or at least where to put the boundaries. Hint: There is a cost to it, just as the cost of updating a monolithic codebase.

@Alex-lu4po 3 ай бұрын

Oh. Would love that!

@bjojosimpson Ай бұрын

Exactly. A module is not an entity, instead the same rules applied to find the boundaries of a Microservice can be applied to design a module. A module can have just a single entity if it doesn't depend on anything else in the system.

@bjorkgren.tobias 3 ай бұрын

Will be an interesting watch!

@OttoGebb 3 ай бұрын

> Meaning changes when going from module to module, here it's not ItemPrice, its CatalogItemPrice. There it's not ItemPrice, it's CartItemPrice. Reminds me of bounded contexts from DDD (the meaning of a laguage term changes from context to context). Why no reference to that, Jimmy?

@FenelZ 3 ай бұрын

(From my experience) people start rolling their eyes every time they hear about complex concepts such as ddd, solid, xp, structured design, etc. it's easier to make them understand the rationale behind the concepts and only then say "...and that's what DDD/SOLID is about"

@greyrabbit2157 3 ай бұрын

@@FenelZ "complex" lmao the only complex thing is my inferiority complex

@fburton8 3 ай бұрын

How many fundamentally different commercial business processes that can be embodied in software are there really, given that details can be parameterized or templated? Am I wrong in thinking the same wheels are being reinvented over and over again?

@alberthalbert1153 3 ай бұрын

> Am I wrong in thinking the same wheels are being reinvented over and over again? No, your hunch is absolutely correct. That's why GitHub exists - programmers got tired of writing the same stuff over and over.

@weareham3068 Ай бұрын

They definitely are being reinvented over again, but that’s because people have slightly different business structures even in the same industry. If every business were structured exactly the same, there would be no differentiation in the market. For example, everything involved in home maintenance would be easier and cheaper if every house were identically built. However, for a variety of reasons, we would never do that.

@juveraey 2 ай бұрын

been there 3years counting. not seeing the ends yet. decoupling is hard

@nove1398 3 ай бұрын

When was this originally aired

@pohjoisenvanhus 2 ай бұрын

It seems that the event itself where this was recorded was in May this year.

@marcm3623 3 ай бұрын

3:56 bis 6:30 the Problem with boundaries and Microservices, führt zu wir wollen Modularisierung ohne big ball of mudd

@StingSting844 2 ай бұрын

While the ideas are okay i still don't see how this enables us to deploy easily without stepping on other teams' toes. Thats an incredibly huge benefit of microservices. Also if we have follow these rules to build maintainable monoliths why can't we follow the proper microservices rules?

@weareham3068 Ай бұрын

Did you watch the video? His whole point is that you won’t know where to draw the boundaries around your micro services until you start building as a monolith. You figure out which features should be grouped into modules (microservices) by investigating how frequently they reference each other; not the other way around.

@MatthijsWagemakers 14 күн бұрын

@@weareham3068 It's a fair point though. This works when there are not a lot of teams and inter-team communication is extremely good. Multi-team Modular Monoliths are nice for getting the initial setup done but you'll want to have an exit strategy ready when the application grows

@bfg5244 3 ай бұрын

25:54 hidden ads exposed

@Elmiger 3 ай бұрын

Most of these points seem to be applicable to microservices in a monorepo aswell. Yes deployment topics are difficult but there is a high chance that you are going to end up with threading/performance issues on huge services which are no bit easier to debug imho. Once you run into performance / memory issues you probably wish you could narrow the search down to one kubernetes pod of service x instead of "the application". Not saying i dont like modular monoliths, they are the way to go for new projects id say. But nothing more.

@Rick104547 3 ай бұрын

There are many ways of finding performance bottleneck to for instance an endpoint (just logs will give you that) or even line level with profilers. Not sure how microservices makes that easier imho.

@Elmiger 3 ай бұрын

@@Rick104547Sure, never said its impossible :) multiple deployment units should have less complexity and therefore less potential breaking points. Splitting off functionality that is mature to some degree seems to be the way to go in my opinion. Still, having worked with microservices for quite a while i wouldnt recommend the "micro" part, especially not as a starting architecture for a new project.

@vincentcifello4435 3 ай бұрын

With all due respect, there are so many self-contradictory statements here that one could literally say they are modularizing their application when doing the exact opposite. Where exactly in that vertical slice pipeline from database to ui does it receive or transmit data to another slice? The obvious answer is nowhere. If you are sharing data, then the slice is not modular because it can’t complete its own responsibility. Isn’t that the very essence of a vertical slice? Why even bother discussing vertical slices and modularity if you are going to immediately give up and break encapsulation?

@RomanRodionov-s6l 3 ай бұрын

> Where exactly in that vertical slice pipeline from database to ui does it receive or transmit data to another slice? Usually it happens in Apllication Services or Transaction Scripts > If you are sharing data, then the slice is not modular because it can’t complete its own responsibility. Isn’t that the very essence of a vertical slice? To get different services work together you should always bring some coupling. If your boundaries are correct then the coupling is called "loose"

@StingSting844 2 ай бұрын

Ideals don't usually end up in the implementation though. Someone at some point will make a mistake to break the encapsulation and it's going to end up in the code base.