I find it often helps to look at our real lifes. We have many types of useful abstractions and temporal decoupling there. We tend to work asynchronously, because it makes a lot of sense. Just think of what happens when you go to a restaurant, how the waiters and cooks do their work for many guests. There are such things as message queues (order list, preperation queue, delivery queue). You don't know which person in the kitchen actually makes your meal, nor do the person in the kitchen know who will eat it. You can do other things while waiting. There are many other good examples from real life which can help to model software systems.
I get what you're saying, but if accessing a rest API synchronously with fixed transmission format and url is "tight", what is a mega monolith, a shared database or a big ball of mud? To me those look like "loose" and "looser". Even more so if the url is a runtime parameter that is easily changed.
Yeah, I think the main point is that loose coupling isn't inherently better for everything and there's always some level of coupling between consumer/producers. There are trade-offs between Message Queues vs HTTP calls for example, and we just need be aware of the characteristics of these types of patterns.
Everything depends on one thing or other. That is not the definition of coupling. Coupling implies tight coupling that disallows or making it hard to change what you depend on. Its dependency not coupling. Coupling was meant to refer the mechanism of dependency and not the dependency itself. The moment there is a agreed upon contract, there is a dependency no matter even if you build redundancy into your dependencies.
That is Gregor's definition of coupling. Per ISO/IEC/IEEE 24765:2017 Systems and software engineering - "manner and degree of interdependence between software modules" www.iso.org/standard/71952.html
Good video. I think coupling and cohesion are human problems. They only matter because programs require people to maintain them. And people need order and patterns to process large amounts of data. Remove the people aspect and coupling and cohesion go out the window. Because my machine could care less what what interface exists between two classes. If anything good code is slower than any other code my machine can execute. I know, this is not some revelation, i am just saying, its not a machine problem, its an us problem.
Isn't thinking about all these types of coupling is really overengineering? ok, for sync vs async call i get it, but i can't understand why i should care about other aspects.
Not at all, things change, we sure can build MVPs or POCs without putting much effort on that, but your or others products will change, and that should be taken into account. So you should think what are the coupling points so when the time comes they can be modified without affecting your critical paths.
@@arielmoraes9427 I agree, things gonna change, but let's think about the Location aspect, what's wrong with storing these info in the .env file? it changed? great just change the info you have in the .env, why should we make things complex?
@arielmoraes9427 I agree, things gonna change, but let's think about the location aspect, what's wrong with storing these info in the .env file of the project? why should i move these info a managed service? doesn't that make things complex for no actual reason?
You're getting to the root of it. You're solution to that coupling is to store it in a single place (env file). Is that overengineering? No, because it's basic enough to you probably in your context that that would work. In a different context, the location of something might not be trivial on how that's defined/stored.
A should not know/care that B will process it. i was following for about a month both you and Milan, and after a while it all becomes confusing as in some videos you are contradicting yourself (its very informative nevertheless) . but that constant content churn-out in order to monetize is backfiring... it now turns into technology attrition and disinteresting
And A doesn't care, but B HAS to care, it doesn't have to care that A specifically give it what it needs, but it has a dependency on ingested data. The point is, there is no silver bullet, there are tradeoffs that have to be managed. I.E. reliable software development is not easy. Don't let anyone sell you otherwise. But, most products don't need to be ultra reliable, so again, there are trade-offs.
For commands, you absolutely know/care that B will process it. If it's a command, the intent is you want something to occur. As for an event, A shouldn't know or care, agree. But B absolutely cares if A stops publishing that event. Curious to know when I'm contradicting myself? I post one video a week. I don't do this full-time. There's no content churn-out, just consistency of posting things I think are worth explaining based on my own experience.
A doesn't care, but there is a reason why A and B exists. So at that level someone does care about that A and B works, and B does something when something happens in A...
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
I find it often helps to look at our real lifes. We have many types of useful abstractions and temporal decoupling there. We tend to work asynchronously, because it makes a lot of sense. Just think of what happens when you go to a restaurant, how the waiters and cooks do their work for many guests. There are such things as message queues (order list, preperation queue, delivery queue). You don't know which person in the kitchen actually makes your meal, nor do the person in the kitchen know who will eat it. You can do other things while waiting. There are many other good examples from real life which can help to model software systems.
Exactly. I did a video on this that async workflows are everywhere including a restaurant. ruclips.net/video/87fOMcRPDts/видео.html
More levels of indirection doesn't reduce coupling; hatoes just moves it from a load bearing url to a load bearing arbitrary string.
TLDR: The only way to achieve a decoupled system is to not have a system!
Exactly!
You still have to have a system, it’s just one layer removed: a meta-system
😂😂😂🤣
I get what you're saying, but if accessing a rest API synchronously with fixed transmission format and url is "tight", what is a mega monolith, a shared database or a big ball of mud? To me those look like "loose" and "looser". Even more so if the url is a runtime parameter that is easily changed.
Hi Derek. Nice video, appreciate it. Coupling and cohesion are the roots of all architectural matters.
Boils down to that a lot of the time
i didnt get if there is any solution to this coupling
Yeah, I think the main point is that loose coupling isn't inherently better for everything and there's always some level of coupling between consumer/producers. There are trade-offs between Message Queues vs HTTP calls for example, and we just need be aware of the characteristics of these types of patterns.
Ok. So the video Is intended to be people aware of
Yes, it's about awareness. Too often we think things are loosely coupled incorrectly or that it isn't coming at a a price/trade-offs.
thanks for the video
Everything depends on one thing or other. That is not the definition of coupling. Coupling implies tight coupling that disallows or making it hard to change what you depend on. Its dependency not coupling. Coupling was meant to refer the mechanism of dependency and not the dependency itself.
The moment there is a agreed upon contract, there is a dependency no matter even if you build redundancy into your dependencies.
That is Gregor's definition of coupling. Per ISO/IEC/IEEE 24765:2017 Systems and software engineering - "manner and degree of interdependence between software modules"
www.iso.org/standard/71952.html
New Derek Coupling video!
They never end!
HTTP API seems so hard to say
It usually comes out as a string of letters
Good video. I think coupling and cohesion are human problems. They only matter because programs require people to maintain them. And people need order and patterns to process large amounts of data. Remove the people aspect and coupling and cohesion go out the window. Because my machine could care less what what interface exists between two classes. If anything good code is slower than any other code my machine can execute. I know, this is not some revelation, i am just saying, its not a machine problem, its an us problem.
Isn't thinking about all these types of coupling is really overengineering?
ok, for sync vs async call i get it, but i can't understand why i should care about other aspects.
Not at all, things change, we sure can build MVPs or POCs without putting much effort on that, but your or others products will change, and that should be taken into account. So you should think what are the coupling points so when the time comes they can be modified without affecting your critical paths.
@@arielmoraes9427 I agree, things gonna change, but let's think about the Location aspect, what's wrong with storing these info in the .env file? it changed? great just change the info you have in the .env, why should we make things complex?
@arielmoraes9427 I agree, things gonna change, but let's think about the location aspect, what's wrong with storing these info in the .env file of the project? why should i move these info a managed service? doesn't that make things complex for no actual reason?
You're getting to the root of it. You're solution to that coupling is to store it in a single place (env file). Is that overengineering? No, because it's basic enough to you probably in your context that that would work. In a different context, the location of something might not be trivial on how that's defined/stored.
A should not know/care that B will process it. i was following for about a month both you and Milan, and after a while it all becomes confusing as in some videos you are contradicting yourself (its very informative nevertheless) . but that constant content churn-out in order to monetize is backfiring... it now turns into technology attrition and disinteresting
And A doesn't care, but B HAS to care, it doesn't have to care that A specifically give it what it needs, but it has a dependency on ingested data. The point is, there is no silver bullet, there are tradeoffs that have to be managed. I.E. reliable software development is not easy. Don't let anyone sell you otherwise. But, most products don't need to be ultra reliable, so again, there are trade-offs.
For commands, you absolutely know/care that B will process it. If it's a command, the intent is you want something to occur. As for an event, A shouldn't know or care, agree.
But B absolutely cares if A stops publishing that event. Curious to know when I'm contradicting myself? I post one video a week. I don't do this full-time. There's no content churn-out, just consistency of posting things I think are worth explaining based on my own experience.
A doesn't care, but there is a reason why A and B exists. So at that level someone does care about that A and B works, and B does something when something happens in A...