SOLID Principles? Nope, just Coupling and Cohesion

How do we avoid writing spaghetti code so our systems don't turn into a hot mess? For me Coupling and Cohesion. Some people focus on things like SOLID principles and Clean Architecture. While I don't necessarily have a problem with that if you're pragmatic, I don't ever really think about either of those explicitly.

🔗 EventStoreDB

💥 Join this channel to get access to source code & demos!

🔥 Don't have the JOIN button? Support me on Patreon!

0:00 Intro
1:05 Coupling & Cohesion
3:22 Highly Cohesive Boundary
8:20 Loose Coupling
10:09 Technical Concerns

#softwarearchitecture #softwaredesign #codeopinion

[maxkomarow]

Thanks man. You've just organized a lot of mess that i've been struggling with after learning about solid, clean architecture, ddd and some other stuff. I think its important to dig through those concepts to not only to understand what they are, but why they are. And from understanding those underlying core things that drive everything else, you can gain a lot of understanding of what to do when and why

[gds_]

I would wish to know developers more like you. Pragmatic and specially avoid complexity. Sometimes what we need to do is so basic, and it seems we are building a spaceship for nothing. And then in the end don't even is able to take off..

[Parthibansekar]

I often hear people saying SRP means doing only one thing. You have clearly explained what that one thing should be. Great video! Thanks!

[timidboy]

Great video! I would really love to hear your take on testing as well, unit testing, integration testing, TDD, etc. 😀

[Nots]

Thanks, actually coupling and cohesion are part of GRASP which in my opinion is more practical and applicable for modern architecture than SOLID.

[marna_li]

I think you touched a point there. SOLID and Clean Architecture both encompass several principles. Buzz words, mostly. The terms are a ways to codify and popularize these principles. There is a lot of opinionated stuff besides that and a lot of “templates”. But once you understand coupling and cohesion from a pragmatic perspective then you can order your stuff around however you want since you understand how to handle complexity.

[MrSpyTubes]

Thanks for your insights. You have bold statements but always reasonable. I really appreciate your labor for sharing your experience

[splendorman]

thanks for awesome video. It is so much clear now. I've been trying to get my head around this topic for the last 2 weeks.

[Mark]

I love the idea of Coupling and Cohesion so much more than SOLID. It's so much simpler and more elegant.

I would add one more "C" to it, though. 'Continuity". Functionality should never break after you make a change. You can overload functions and add optional parameters, but old method signatures should continue to work and work the same way.

[cccc]

great content, i'll incorporate this approach into my designs

[archmad]

this what i similarly do in the frontend. group to features, shared uis/utilities and data. Then inside a feature, will have all my codes, may also have shared folders within

[ReVivL]

I do believe most people build simple apps that do not require any coupling fighting. But then, once you start trying to write an app that implements business processes, you need to start thinking about behavior, events, and coupling. Even though I had my fair share of experience, I enjoyed this vid. Great work.

[vindecode]

do you have top 10 books that you can recommend ? would love to hear from you 🙂

[LxQP]

5:07 Assume my UI has Name, Price and Quantity which an user can initially define when creating a new product. Is the UI required to send the Create request to each Service? My idea was to only provide a Create REST Endpoint within the Catalog module and internally using Domain and Integration Events like ProductCreated which then can be consumed by Warehouse for example. But this approach would require the Catalog Module to pass the quantity within the ProductCreated event. How could one avoid this?

[emanueltrandafir]

Hello, thanks for the video, the content is great and super usefull!
Though, i still believe the solid Principles are quite usefull. I believe that, at a deeper level, they are all about coupling and coehision.
For example, you have already mentioned s.r.p. Then, o.c.p encourages polymorphism and dependency inversion, Therefore allowing various implementations to stay in different modules or services rather than putting them into the same place.
Also, i.s.p. can be understood as "you should only depend on what you need". Breaking the interfaces into smaller ones is also something that will lead to a higher coehision of the respective component.

[coderider]

I do proper solid with my C# and have done for many years. I get told …. ‘Nobody likes an uncle bob’ by those that wrote the most awful code I’ve seen in my 25yrs

[michaelstewart]

Hi Derek! When you split your product entity to support different capability centric services, do you still keep one table on the database or you split it there too ? Can I have different aggregate roots or entities from the same table ? 🤔

[timmetcalfe]

Very good advice. Your video makes it obvious that focusing on entities so much is the wrong approach.

[RasmusSchultz]

7:12 why are "Models" not organized under "Features" with the features that they belong to? (is the model as a whole separate from features for design reasons? for example, I'm wondering if e.g. Checkout might also need access to the ShoppingCart and maybe that's why? do you generally keep the model separate from the features, even if the codebase is organized by feature?)

[viktorasmickunas]

Really makes sense. There's only one thing that bothers me: sometimes you have to distribute code that could be part of one class to separate classes just to be able to unit test them (move them from the private methods of the original class to the public ones of a new class). In one sense it lowers cohesion and creates a new coupled class with the functionality that would benefit from being in one cohesive unit, on the other hand this makes functionality a lot more unit testable. Or is this more about micro service boundaries? What's your take on this?