Modularizing the Monolith - Jimmy Bogard - NDC Oslo 2024

Поделиться
HTML-код
  • Опубликовано: 27 дек 2024

Комментарии • 32

  • @kedzior-io
    @kedzior-io 3 месяца назад +2

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

    • @theanswer_19
      @theanswer_19 2 месяца назад +1

      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
    @TechTalksWeekly 4 месяца назад

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

  • @bjorkgren.tobias
    @bjorkgren.tobias 4 месяца назад

    Will be an interesting watch!

  • @brynyard
    @brynyard 4 месяца назад +9

    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
      @Alex-lu4po 4 месяца назад

      Oh. Would love that!

    • @bjojosimpson
      @bjojosimpson 2 месяца назад +1

      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.

  • @juveraey
    @juveraey 3 месяца назад

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

  • @OttoGebb
    @OttoGebb 4 месяца назад +4

    > 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
      @FenelZ 4 месяца назад

      (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
      @greyrabbit2157 4 месяца назад

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

  • @fburton8
    @fburton8 4 месяца назад +2

    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
      @alberthalbert1153 4 месяца назад

      > 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
      @weareham3068 2 месяца назад

      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.

  • @marcm3623
    @marcm3623 4 месяца назад

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

  • @nove1398
    @nove1398 4 месяца назад

    When was this originally aired

    • @pohjoisenvanhus
      @pohjoisenvanhus 3 месяца назад +1

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

  • @djgreyjoy1495
    @djgreyjoy1495 16 дней назад

    To be successful with this approach you need proper modules, but mainstream programming languages only have global exports - it's like having only global variables. True modules require proper information hiding, but instead of implementing this in languages (like Ada did) they chose the easy path in the name of simplicity. The solution was there decades ago. That "simplicity" generated all this complexity. You have what you deserve.

  • @StingSting844
    @StingSting844 3 месяца назад +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
      @weareham3068 2 месяца назад

      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
      @MatthijsWagemakers Месяц назад

      @@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
    @bfg5244 4 месяца назад +2

    25:54 hidden ads exposed

  • @Elmiger
    @Elmiger 4 месяца назад +6

    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
      @Rick104547 4 месяца назад +4

      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
      @Elmiger 4 месяца назад +1

      ​@@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.

  • @mymacaintwag
    @mymacaintwag 24 дня назад

    Everything is just a big misunderstanding.

  • @vincentcifello4435
    @vincentcifello4435 4 месяца назад +4

    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
      @RomanRodionov-s6l 4 месяца назад

      > 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
      @StingSting844 3 месяца назад

      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.

  • @Alphabet12333
    @Alphabet12333 Месяц назад

    tbh in every video he talks so much and says what is wrong and bad but hardly tells how to do it right. Often a waste of time to hear him 😕

  • @JonasThente-ji5xx
    @JonasThente-ji5xx 4 месяца назад +1

    First

  • @flashflexpro
    @flashflexpro 4 месяца назад

    JAVA OSGI ?