I have rarely seen such clearly understandable and at the same time short and concise videos on relevant software design topics as those by Vaughn Vernon in this playlist. Absolutely worth watching!
Great video and perspective of an overlooked aspect. There are clear cases when bad coupling has occurred and should be removed (decoupled), such as business logic using functions/objects in a web tier. But I also think that "decoupling" is often used for the meaning "reduction of tight coupling". The tighter the coupling, the more difficult it is to replace/modify a particular component/subsystem. Reduction of tight coupling often introduces new abstractions, and (as always) one needs to balance the cost/benefits of new abstractions.
Thank you for the great explanation. I think it's important to clarify coupling in terms of context. If two components, A and B, are coupled with respect to changes in B's API, but B's API is guaranteed to never change, then it's not really coupling. For example, using a programming language is not considered coupling if the language's API is fixed and will never change. From this perspective, design becomes a matter of hiding changes behind interfaces that are less likely to change.
Sorry, but no. If nothing is coupled to B, B does nothing. A is coupled to B regardless of B's stability. BTW, from a business perspective, and assuming B is useful at the business level, if B never changes, you haven't learned anything.
I view coupling, and cohesion as well, as dependency and knowledge. If A couples to B, then A depends upon and has knowledge of B. B has no coupling, dependency nor knowledge of A. If B is stable and never changes, then it's stable dependency and knowledge. The dependency is still there, but it may never become a modification issue.
@@jimhumelsine9187 My point is, we should say A is coupled to B with respect to changes in B's API. In addition to specifying the dependency, we must tell with respect to what change. If the change never happens, its not a dependency.
@@MohamedKamal-wd8hx Taking your idea to the extreme you could have all the project in a single file and you could argue that nothing is coupled to anything if nothing changes. Two things are truly decoupled when nothing defined in the boundaries of these things can possibly affect each other. If any B operation depends on any understanding of something defined by A, regardless the layers of indirection, then they are coupled. Also, specially in your example, because you are assuming that what is couplin both services will not change, is were you should be the most aware that this coupling exists.
I have rarely seen such clearly understandable and at the same time short and concise videos on relevant software design topics as those by Vaughn Vernon in this playlist. Absolutely worth watching!
Thanks!
Thanks Vaughn. Nice one, appreciate it.
Great video and perspective of an overlooked aspect. There are clear cases when bad coupling has occurred and should be removed (decoupled), such as business logic using functions/objects in a web tier. But I also think that "decoupling" is often used for the meaning "reduction of tight coupling". The tighter the coupling, the more difficult it is to replace/modify a particular component/subsystem. Reduction of tight coupling often introduces new abstractions, and (as always) one needs to balance the cost/benefits of new abstractions.
Thank you for the great explanation. I think it's important to clarify coupling in terms of context. If two components, A and B, are coupled with respect to changes in B's API, but B's API is guaranteed to never change, then it's not really coupling. For example, using a programming language is not considered coupling if the language's API is fixed and will never change. From this perspective, design becomes a matter of hiding changes behind interfaces that are less likely to change.
Sorry, but no. If nothing is coupled to B, B does nothing. A is coupled to B regardless of B's stability. BTW, from a business perspective, and assuming B is useful at the business level, if B never changes, you haven't learned anything.
I view coupling, and cohesion as well, as dependency and knowledge. If A couples to B, then A depends upon and has knowledge of B. B has no coupling, dependency nor knowledge of A.
If B is stable and never changes, then it's stable dependency and knowledge. The dependency is still there, but it may never become a modification issue.
@@jimhumelsine9187 My point is, we should say A is coupled to B with respect to changes in B's API. In addition to specifying the dependency, we must tell with respect to what change. If the change never happens, its not a dependency.
@@MohamedKamal-wd8hx "You keep using that word. I do not think it means what you think it means.” -Inigo Montoya 😊
@@MohamedKamal-wd8hx Taking your idea to the extreme you could have all the project in a single file and you could argue that nothing is coupled to anything if nothing changes.
Two things are truly decoupled when nothing defined in the boundaries of these things can possibly affect each other.
If any B operation depends on any understanding of something defined by A, regardless the layers of indirection, then they are coupled.
Also, specially in your example, because you are assuming that what is couplin both services will not change, is were you should be the most aware that this coupling exists.