This talk is as relevant and insightful today as it was 5+ years ago. It should have way, way more views and likes and discussion. Like most, I've seen and suffered under both extremes... horrifying, ancient big balls of monolithic mud where it was terrifying to change anything vs. knee-jerk microservice zealotry. I'm trying to find and promote a bit of sanity by adopting modular monoliths. The devil's definitely in the details. I'm still trying to get my head around the practical considerations of data encapsulation/boundaries when so much data has been traditionally shared (JOINs, JOINs everywhere). But this is a great overview and a thought-provoking reminder that good design is good design. Thank you, Simon!

Pure Gold. Finally, we are rescuing the foundational principles of how to make good software from to the roots of our industry and appliying those principles on modern technologies. Fantastic.

Thank you for a very insightful and intelligent talk.

Definitely the best talk I ever saw on software architecture!

Great talk! A lot of things boil down to common sense.

"Choose microservices for the benefits, not because your monolithic codebase is a mess"

Great and interesting talk! I like the idea that we should first start up with modular monolith and than switch to microservices eventually. Thanks!

Setting strong foundations and setting it right at the very start, enjoyed it thoroughly...

Very nice, explained exceptionally well

awesome!! thanks

Perfect!

Great talk Simon Thanks.

I just re-read the missing chapter this weekend. Didn't put it together that it was /this/ Simon Brown. Good stuff!

I would like to throw modules into the 'Java doesn't have a component keyword" debate

That was really good

I use "Package by Feature" but each package has own additional package with Contracts. Thanks to that I can make everything private also with controller into that package and external package can use Contracts (which are public and this is only referenced by other features) to use functions from that package. Nice and clean.

@marikselazemaj3428

3 жыл бұрын

I don't understand what you are saying. but it sounds like a good thing.

@removed107

3 жыл бұрын

@@marikselazemaj3428 Hahaha, relax.

Amazing talk! I am still trying to answer one question in all the 4 approaches, how to communicate with other components? Like Orders component needs information from the Customer component, how and where the two components communicate to get information, Order getting information about the Customer in all the 4 approaches

@m.yousuf3899

Жыл бұрын

kzread.info/dash/bejne/f5-Y19azhqWZoLw.html&ab_channel=DevMentors This video has a lot of implementation-related details about modular monoliths.

Simon Brown is such a treasure trove of accessible insight on complex architectures (and a fox to look at too), love his talks.

Great talk, Simon is certainly one of the best when it comes to delivering actionable, no-nonsense wisdom. Coming from Rails, I'd certainly find it beneficial to be able to "slice the monolith up vertically", hiding some group of models/services from the rest while being able to define public interfaces that are OK to access from anywhere. Engines?

"People use microservices to enforce code boundaries", do they really? Yes it is the ultimate form of code boundaries but that's not the reason for doing it. The reason is the possibility to deploy and scale parts of the application independently.

@sealoftime

2 жыл бұрын

Whether your component is a microservice or not is a detail of implementation, in my opinion. Scaling a component should not be a task much harder than separating an interface from a class. As such, you do not need the microservice architecture to scale your application in the first place, but microservices naturally arise, when the intent to scale only a part of components in your monolith begins.

Ok. Good. What should I do, if I don't use spring annotation configuration? How can I create impl classes with package modifier? I know only one way - spring annotation configuration. Architecture for spring?

Hey, isn't Simon Brown the C4 software architecture guy? Documentation = The Architecture.

I would make the controller package protected. Spring can instatiate it. Nobody from code needs to invoke it.

Thanks…How would an order component communicate with another component say user management to authenticate users for example if you decide to modularise them?

"Clean architecture" /Onion can have also a huge overhead in simple systems. E.g. Forcing always!(!) every call to go from webcontroller DTOs, to domains (domain object) Is what I call a mapping-hell.

I somehow missed the part where he talks about modular monoliths in any detail. Some good information in places, but I'm still not sure what a modular monolith is after this talk.

Great talk. My OCD is being triggered by the slide at 30:30

Me: "The root cause of our problems is poor encapsulation." My boss: "That sounds like a code-level thing. Get your head out the sand." Engineer: "We've added a thing for that."

Thanks man, those were the last words convincing me that microservices are not the way to follow at least not now for the application I'm building, and the n of people working on it (just me). I don't know why, but I realised that microservices maybe are following what human interaction is like in these days: people tend to stay more in their little worlds, instead of trying to be a part of a whole thing. Communication most of the time is not very good, and costs a lot. LOL 😂 .... Anyway, my concern is an asynchronous service that runs an heavy algorithm, and I'm thinking about isolating, it in order to run N instances in parallel. I have lots of perplexities regarding the data produced by this service, due to the fact that one instance cannot be unaware of what the other is doing, in order to produce a good (and feasible) result. I mean... What the hell! Do we really need to learn containerization? Why do we need to throw away years of good stuff (relational databases, just to say one)? Wouldn't be simpler to have a smarter JVM, capable of a container like features only where needed? Excuse my ignorance about the topic, I really appreciate how fast you can setup an environment with docker, but.... I think that better solutions still have to come in the next years, and maybe they will be a good balance between the past techniques and the present ones... Balance!! It's always the best solution!

Too bad I've started learning about distributed monoliths only after I've wasted 3 years working on one. Well, I didn't have the experience, I went to work on a system I did not understand from the domain perspective, it turned out later on that it is actually a distributed monolith because of various dependencies I did not know about. So pls, understand the domain before jumping on coding, do what Simon is talking about, you will save yourself a lot of pain, lost time and lost money for the company you work for...

I don't think everything has to be a first class citizen. From my experience, it will get abused. Just like "Service" - XService, YService, BlablaService, UselessService. All the services. Its tiring. 13:30 - I would say it is better because the concept of feature is better contained than the concept of layer. Every time I went from layers to vertical slicing my solution, I found that I understand and navigate the code much easier afterwards.

The problem I have been facing in architecture

Hah "CV Driven Design"

@MaximilienDanton

3 жыл бұрын

I am definitely using this one!

OSGi to the rescue.

CV-driven design! lol

"... we just type 'public' by default and we don't know why. It's muscle memory..." That's what kills the modular design principle...

"Tweet component does not actually exist when you zoom in." Do you also think a building you just entered into does not exist as well?

@xucongzhan9151

3 жыл бұрын

Well, I'd argue "zooming in" is not the same as "entering", but much closer to "walking up to" (a building). Having an actual Tweet module VS having a conceptual Tweet module that consists of two files/classes which sit among other files for other features, is different IMO.

Love Simon's work and content, surely the answer is to stop using Java ;) (joking, but kinda not)

*TL;DW* Don't do microservices to make your code base more modular do it because you really need to be able to deploy and scale parts of your application separately. Instead make your codebase more modular by using a better package structure and careful use of *public* classes. (Interesting talk but could have been done in 15 minutes)

@removed107

3 жыл бұрын

Thanks, my friend.

Concept driven development? To which problem the solution is? Business? Code structure should rather reflect organizational structure. At least, this (org.structure) seems to be much more stable than rapidly changing functions, technologies and context. The architecture evolves dramatically while organizational structure doesn't! The more the drivers for codebase are stable, the less effort/risk/spending/learning curve is.

@0xIAMROOT

5 жыл бұрын

When you say org structure, what do you mean? Frontend, backend, db, etc? Just need clarification.

@burningdog2

4 жыл бұрын

This would be Conway's Law in action.

I thought this was obvious to most people? 😅🤔

"All these programmers are cargo cult programmers that follow what somebody is saying." - Presenter "Here, I have my own cargo." - Also the Presenter

@muyewahqomeyour7206

Жыл бұрын

😀 Well, at least the presenter in this case explains the reasons

Super boring, outdated, old.

@PetiKoch

4 жыл бұрын

I'm kind of a Newbie and interested in your opinion. Could you add some more details why the talk is for you "super boring, outdated, old."? Are you probably not the "target audience" (e.g. beginner/intermediate but not expert)? What talk recordings, books, blog posts, etc would you recommend to other "more expert" people in this field to get some good "learning stuff"? Thank you for your help from an another human being trying to "understand better"! Peti

@bariole

4 жыл бұрын

@@PetiKoch I am guessing here, but brobably anything which isn't microservice lambda serverless reactive stream is super boring outdated old stuff.

@midclock

3 жыл бұрын

Tell us more about your avatar... It looks brand new!

@MaximilianBerkmann

3 жыл бұрын

Do you mind expanding on how it is outdated and old?

@baumannalexj

2 жыл бұрын

@@PetiKoch Ignore him. Starting at 34:36, from here on should be a blueprint for startups. Start with a monolith, work on developing bounded business contexts "in-process" by increasing cohesion and decreasing coupling (modules + interfaces), before moving your cohesive modules "out-of-process" (microservices)