curriculum-foundation
curriculum-foundation copied to clipboard
LG 03-04 ?? (V2025) rewrite the LGs for coupling
differentiate between at least the following categories of coupling:
- static and dynamic coupling, as explained in [Ford+21]
- efferent and afferent coupling
- other types of coupling (e.g. hardware/infrastructure, temporal, data, data-structure, content etc)
@gernotstarke What Is [Ford+21]?
Aren't efferent and afferent coupling metrics?
https://en.wikipedia.org/wiki/Software_package_metrics
I'm all for clarifying what we mean by "different types of coupling"
Aren't efferent and afferent coupling metrics?
https://en.wikipedia.org/wiki/Software_package_metrics
Yes Mike, one can measure these types of coupling (incoming, outgoing)... at least in theory. In practice, static versions of both can be measured, if they occur at runtime, you can only count calls in your logfile :-)
I like the distinction "who depends on me" and "who am I dependent on"...
@gernotstarke What Is [Ford+21]?
"The Hard Parts": [Ford+21] Neal Ford, Mark Richards, Pramod Sadalage und Zhamak Dehghani: Software Architecture: The Hard Parts. Modern Trade-Off Analyses for Distributed Architectures. OReilly 2021.
I like the distinction "who depends on me" and "who am I dependent on"...
Furthermore I like the distinctions:
- When does this dependency has to be fulfilled? (binding, compile time vs run time)
- Is this dependency visible in code? (depending on chosen implementation techniques)
- Is this dependency aligned with the actual dependency from the domain? (if applicable)
- What is the mode of this dependency? (time, cause-effect, structure, technology, organizational, technology, ...)
- Is it uni or bi-directional?
- Is it "strong" or "weak"? (Yes, that's hard to quantify. But most people will agree that inheritance and structural coupling are "strong" while coupling by events/messaging is "weak".)
- maybe some more ...
for binding time: [Ford+21] proposes "static vs dynamic" as top-level distinction. Then efferent/afferent.
all static deps are visible in code (per definition).
What would we suggest people do with this distinction?
What would we suggest people do with this distinction?
Let them consider how this kind of coupling affects the qualities (especially maintainability, flexibility, understandability, testability, and analyzability) of their software system and its architecture and how changing them could benefit in achieving desired qualities or at least what kind of trade-offs they pose.
those Microservice fanboys who still believe that getting rid of compile-time dependencies will make their lives easier... because they forgot to consider the consequences on dynamic coupling.
those Microservice fanboys who still believe that getting rid of compile-time dependencies will make their lives easier... because they forgot to consider the consequences on dynamic coupling.
I like that - but then let's make it explicit: "... know that forgoing static dependencies in favor of dynamic dependencies does not necessarily reduce the underlying coupling"
FLWG: Do this, with @mikesperber 's suggestion