🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧱 धडा 02 — Modularity: कमी मार्गिका असलेल्या खोल्या, मोजून

📍 तुम्ही इथे आहात: 12 पैकी धडा 02 · मागे: lesson-01-what-is-architecture · पुढे: lesson-03-layers

📦 या ब्रँचमध्ये काय आहे

धडा 01, आणि मोजमाप. Cohesion (एका खोलीतल्या गोष्टी एकत्र असायला हव्यात का?) आणि coupling (किती मार्गिका आत येतात आणि बाहेर जातात?), यांचे तुम्ही लक्ष ठेवू शकाल अशा आकड्यांत रूपांतर: afferent coupling Ca, efferent coupling Ce, instability I, abstractness A आणि main sequence पासूनचे अंतर D — Robert C. Martin यांचे package metrics — आणि त्यासोबत एक सोपा relational-cohesion आकडा H. arch/analyze.py मधील coupling() आणि arch/demo.py मधील modularity().

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळेच्या चांगल्या इमारतीत प्रत्येक खोलीचे एकच काम असते. Science lab मध्ये test tubes असतात. ग्रंथालयात पुस्तके असतात. अर्ध्या test tubes ग्रंथालयात ठेवत नाहीत. हेच cohesion: एकत्र वापरल्या जाणाऱ्या गोष्टी एकत्र राहतात.

आणि चांगल्या खोलीला दहा दारे नसतात. Science lab ला इतर प्रत्येक खोलीकडे दार असते, तर मुले दिवसभर तिच्यातून ये-जा करत राहिली असती, आणि कोणालाही धक्का न लावता आत काहीच बदलता आले नसते. हेच coupling: खोलीला जितक्या कमी मार्गिका लागतात, तितकी ती बदलायला सोपी.

दीपिका प्रत्येक मजल्याची दारे मोजते. आत येणारी दारे (ज्यांना या मजल्याची गरज आहे असे लोक) मजला बदलायला अवघड करतात — अनेक जण त्यावर अवलंबून असतात. बाहेर जाणारी दारे (या मजल्याला लागणाऱ्या गोष्टी) त्याला सहज डळमळीत करतात — दुसरा मजला बदलला की याला जाणवते.

🗺️ आकृती

flowchart LR
    app["🧑‍🏫 app floor<br/>Ca 2 · Ce 3 · I 0.60"]
    domain["📚 domain floor<br/>Ca 5 · Ce 2 · I 0.29 · A 0.33"]
    infra["🔌 infra floor<br/>Ca 3 · Ce 2 · I 0.40"]
    web["🖥️ web floor<br/>Ca 2 · Ce 1 · I 0.33"]
    main["🔑 main<br/>Ca 0 · Ce 1 · I 1.00"]
    main --> app
    main --> web
    main --> infra
    web --> app
    app --> domain
    app --> infra
    domain --> infra
    domain --> web
    infra --> domain

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/software-architecture/lesson-diagrams.html#l02

❓ काय

Cohesion — एका module चे भाग एकमेकांशी किती घट्ट जुळलेले आहेत. Larry Constantine आणि Edward Yourdon यांनी Structured Design (1979) मध्ये त्याचे प्रकार वर्णन केले; functional cohesion (सगळे एकाच कामासाठी) सगळ्यात चांगले, coincidental (एक utils.py सारखी खिचडी) सगळ्यात वाईट.
Coupling — एक module इतरांवर किती अवलंबून आहे. कमी म्हणजे नेहमीच चांगले नाही — शून्य coupling म्हणजे भाग एकत्र कामच करत नाहीत — पण प्रत्येक coupling गरजेचे आणि योग्य दिशेने असायला हवे.
Component — एकत्र release होणाऱ्या आणि एकत्र विचार केल्या जाणाऱ्या modules चा गट (एक Python package, एक Java JAR). इथे: एक मजला (web, app, domain, infra, आणि main). Martin यांचे metrics classes मोजतात; lab त्यांच्या जागी modules मोजतो.
Ca, afferent coupling (fan-in) — component च्या बाहेरचे किती modules त्याच्या आतले एखादे module import करतात. जास्त Ca = अनेक जण त्यावर अवलंबून = जबाबदार, बदलायला अवघड.
Ce, efferent coupling (fan-out) — component च्या आतले किती modules बाहेरचे काहीतरी import करतात. जास्त Ce = ते खूप गोष्टींवर अवलंबून = सहज डळमळीत.
Instability I = Ce / (Ca + Ce) — 0 म्हणजे जास्तीत जास्त स्थिर (फक्त इतर त्यावर अवलंबून), 1 म्हणजे जास्तीत जास्त अस्थिर (फक्त तेच इतरांवर अवलंबून). Stable Dependencies Principle: स्थिरतेच्या दिशेने (कमी I कडे) अवलंबून राहा.
Abstractness A — component मधील abstract classes ÷ सगळे classes. Lab एखादा class abstract मानतो जर तो ABC किंवा Protocol चा subclass असेल किंवा त्यात @abstractmethod असेल.
Distance D = |A + I − 1| — component "main sequence" पासून किती दूर आहे, जिथे स्थिर components abstract आणि अस्थिर components concrete असतात. A=0, I=0 ला D जवळपास 1 म्हणजे "zone of pain" (स्थिर आणि concrete: कडक). D हा इशारा आहे, गुण नव्हे: क्वचितच बदलणारा स्थिर concrete code (एखादा date helper) तिथे असला तरी चालतो.
Relational cohesion H = (R + 1) / N — component च्या आतल्या R मार्गिका, N modules (NDepend वापरते ते सूत्र). कमी H म्हणजे component मधले modules एकमेकांना जवळपास वापरतच नाहीत — ते कदाचित दुसरीकडे असायला हवेत.

🤔 का

कारण "coupling कमी, cohesion जास्त ठेवा" हा सल्ला सगळ्यांना मान्य असतो आणि कोणीच तपासू शकत नाही. आकडे तो तपासण्याजोगा करतात. एखादा स्थिर component (कमी I) अस्थिर component import करत असेल तर तो Stable Dependencies Principle मोडतो: ज्या गोष्टीवर सगळे टेकतात, ती आता वारंवार बदलणाऱ्या गोष्टीवर टेकते. तुम्ही ते पाहू शकता, त्याचा कल पाहू शकता, आणि — धडा 09 मध्ये — त्यावर build fail करू शकता.

🔧 कसे (या repo मध्ये)

arch/analyze.py मधील coupling(g, classes) खोल्यांना floor(m) (नावाचा पहिला भाग) नुसार गटात टाकतो आणि प्रत्येक मजल्यासाठी मोजतो: N, R, H, Ca, Ce, I, A आणि D. scan() प्रत्येक module चे classes आणि प्रत्येक class abstract आहे का (त्याचे bases आणि decorators, ast ने वाचून) नोंदवतो. apply(g, remove=…) काही मार्गिका काढून graph ची copy बनवतो, म्हणजे files ला हात न लावता तुम्ही एखादा fix करून पाहू शकता.

🧪 करून पाहा

python3 arch/demo.py modularity
python3 - <<'EOF'
import sys; sys.path.insert(0, "arch"); from analyze import scan, edges, floor, coupling, apply
cb = scan(); g = cb.imports
ca = sorted({a for a, b in edges(g) if floor(a) != "domain" and floor(b) == "domain"})
ce = sorted({a for a, b in edges(g) if floor(a) == "domain" and floor(b) != "domain"})
print("Ca (outside rooms that import domain):", ca)
print("Ce (domain rooms that import outside):", ce)
print(f"I = {len(ce)} / ({len(ca)} + {len(ce)}) = {len(ce) / (len(ca) + len(ce)):.2f}")
clean = apply(g, remove=[("domain.grades", "infra.db"), ("domain.timetable", "web.format")])
m = coupling(clean, cb.classes)["domain"]
print(f"without the 2 outward corridors: Ce={m['ce']} I={m['i']:.2f} A={m['a']:.2f} D={m['d']:.2f}")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

modularity हे छापतो:

── per floor (component): N rooms, R corridors inside, H = (R+1)/N, Ca in, Ce out, I = Ce/(Ca+Ce), A abstract, D = |A+I-1|
   app     N=3 R=0 H=0.33 · Ca=2 Ce=3 I=0.60 · A=0.00 D=0.40
   domain  N=5 R=2 H=0.60 · Ca=5 Ce=2 I=0.29 · A=0.33 D=0.38
   infra   N=2 R=0 H=0.50 · Ca=3 Ce=2 I=0.40 · A=0.00 D=0.60
   main    N=1 R=0 H=1.00 · Ca=0 Ce=1 I=1.00 · A=0.00 D=0.00
   web     N=2 R=1 H=1.00 · Ca=2 Ce=1 I=0.33 · A=0.00 D=0.67

तुमचा snippet हे छापतो:

Ca (outside rooms that import domain): ['app.enrol', 'app.fees_service', 'app.report_card', 'infra.db', 'infra.email']
Ce (domain rooms that import outside): ['domain.grades', 'domain.timetable']
I = 2 / (5 + 2) = 0.29
without the 2 outward corridors: Ce=0 I=0.00 A=0.33 D=0.67

🏁 तुम्ही आत्ताच काय सिद्ध केले

Domain मजल्यावर सगळे टेकतात (Ca = 5) — म्हणून तो सगळ्यात स्थिर असायला हवा. दोन मार्गिका हे बिघडवतात: domain.grades → infra.db आणि domain.timetable → web.format. त्या काढल्या की domain ची instability 0.29 वरून 0.00 वर येते. D चे काय झाले ते पाहा: तो 0.38 वरून 0.67 वर, वर गेला, कारण domain आता पूर्ण स्थिर आहे पण फक्त एक तृतीयांश abstract. म्हणूनच D हा इशारा आहे: इथे fix बरोबर आहे, आणि D "स्थिर आणि concrete" म्हणतो — जे फक्त शाळेचे नियम बदलले तरच बदलणाऱ्या business rules साठी सामान्य आहे. app मजल्याचा H = 0.33 आहे: त्याच्या तीन खोल्या एकमेकांना कधीच import करत नाहीत. मजला खोल्यांना प्रकारानुसार गटात टाकतो, कामानुसार नव्हे — धडा 05 त्यांना त्याऐवजी विभागानुसार गटात टाकतो.

⚠️ नेहमीच्या चुका

सगळे import करतात असे utils किंवा common module — प्रचंड Ca असलेले coincidental cohesion
metric वाचण्याऐवजी तो optimise करणे (फक्त Ce कमी करण्यासाठी module तोडणे)
स्थिर, खूप वापरला जाणारा component एखादा अस्थिर component import करतो ("स्थिरतेच्या दिशेने अवलंबून राहा" मोडतो)
फक्त थेट imports मोजणे आणि लांब साखळ्या चुकवणे (धडा 01 चा blast radius)
tools classes, modules की packages मोजतात हे न तपासता त्यांचे आकडे एकमेकांशी तुलना करणे

🏭 प्रत्यक्ष वापरात

On a real project — हे आकडे काढणारी tools:

JDepend (Java) प्रत्येक package साठी Ca, Ce, A, I आणि D देतो — हेच metrics.
NDepend (.NET) ते प्रत्येक assembly साठी देतो, आणि relational cohesion ही.
pydeps (Python) import graph काढतो: pip install pydeps && pydeps yourapp --max-bacon 2.
import-linter (Python) metrics मोजत नाही, पण त्यांच्यावरून तुम्ही ठरवलेले नियम लागू करतो (धडे 03, 04 आणि 09).

फक्त standard library वापरून कोणत्याही Python package चा झटपट fan-in / fan-out count — arch/analyze.py नेमके हेच करतो — scan() तुमच्या स्वतःच्या code कडे वळवा:

python3 -c 'import sys; sys.path.insert(0, "arch"); from analyze import scan, coupling
cb = scan("src", "yourapp"); print(coupling(cb.imports, cb.classes))'

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: प्रत्येक component चे I आणि D CI मध्ये नोंदवा आणि त्यांचा आलेख काढा. ज्या component चा fan-in वाढत असताना instability हळूहळू वर चढते, तो तुमच्या codebase चा पुढचा "कोणी हात लावायची हिंमत करत नाही" असा भाग आहे.

⏭️ पुढे

प्रत्येक मजल्याचे आकडे उपयोगी आहेत. मजल्यांबद्दलचा नियम अधिक चांगला: कोणता मजला कोणाला call करू शकतो? Layers आणि dependency rule.

git checkout lesson-03-layers

🧱 Lesson 02 — Modularity: rooms with few corridors, measured

📍 You are here: Lesson 02 of 12 · Previous: lesson-01-what-is-architecture · Next: lesson-03-layers

📦 What's in this branch

Lesson 01, plus measuring. Cohesion (do the things in one room belong together?) and coupling (how many corridors lead in and out?), turned into numbers you can track: afferent coupling Ca, efferent coupling Ce, instability I, abstractness A and distance from the main sequence D — Robert C. Martin's package metrics — plus a simple relational-cohesion number H. coupling() in arch/analyze.py and modularity() in arch/demo.py.

🧒 Explain like I'm 5

In a good school building, each room has one job. The science lab has the test tubes. The library has the books. You do not keep half the test tubes in the library. That is cohesion: things that are used together live together.

And a good room does not have ten doors. If the science lab had a door to every other room, children would walk through it all day, and nobody could change anything inside without bumping into someone. That is coupling: the fewer corridors a room needs, the easier it is to change.

Dipika counts the doors of each floor. Doors coming in (people who need this floor) make the floor hard to change — many people rely on it. Doors going out (things this floor needs) make it easy to disturb — when another floor changes, this one feels it.

🗺️ Diagram

flowchart LR
    app["🧑‍🏫 app floor<br/>Ca 2 · Ce 3 · I 0.60"]
    domain["📚 domain floor<br/>Ca 5 · Ce 2 · I 0.29 · A 0.33"]
    infra["🔌 infra floor<br/>Ca 3 · Ce 2 · I 0.40"]
    web["🖥️ web floor<br/>Ca 2 · Ce 1 · I 0.33"]
    main["🔑 main<br/>Ca 0 · Ce 1 · I 1.00"]
    main --> app
    main --> web
    main --> infra
    web --> app
    app --> domain
    app --> infra
    domain --> infra
    domain --> web
    infra --> domain

🗺️ Drawn version + a lab: https://school-edh.pages.dev/software-architecture/lesson-diagrams.html#l02

❓ What

Cohesion — how strongly the parts of one module belong together. Larry Constantine and Edward Yourdon described kinds of it in Structured Design (1979); functional cohesion (everything serves one job) is the best, coincidental (a utils.py grab-bag) the worst.
Coupling — how much one module depends on others. Less is not always better — zero coupling means the parts do not work together — but every coupling should be needed and pointed the right way.
Component — a group of modules released and reasoned about together (a Python package, a Java JAR). Here: one floor (web, app, domain, infra, and main). Martin's metrics count classes; the lab counts modules in their place.
Ca, afferent coupling (fan-in) — how many modules outside the component import a module inside it. High Ca = many rely on it = responsible, hard to change.
Ce, efferent coupling (fan-out) — how many modules inside the component import something outside it. High Ce = it depends on a lot = easily disturbed.
Instability I = Ce / (Ca + Ce) — 0 is maximally stable (only depended on), 1 is maximally unstable (only depends on others). The Stable Dependencies Principle: depend in the direction of stability (towards lower I).
Abstractness A — abstract classes ÷ all classes in the component. The lab counts a class as abstract if it subclasses ABC or Protocol or has an @abstractmethod.
Distance D = |A + I − 1| — how far a component is from the "main sequence" where stable components are abstract and unstable ones are concrete. D near 1 at A=0, I=0 is the "zone of pain" (stable and concrete: rigid). D is a hint, not a grade: stable concrete code that rarely changes (a date helper) is fine there.
Relational cohesion H = (R + 1) / N — R corridors inside the component, N modules (the formula NDepend uses). Low H means the modules in the component hardly use each other — they may belong elsewhere.

🤔 Why

Because "keep coupling low, cohesion high" is advice everyone agrees with and nobody can check. Numbers make it checkable. A stable component (low I) that imports an unstable one breaks the Stable Dependencies Principle: the thing everyone leans on now leans on something that changes often. You can see it, trend it, and — in lesson 09 — fail the build on it.

🔧 How (in this repo)

coupling(g, classes) in arch/analyze.py groups rooms by floor(m) (the first part of the name) and counts, for each floor: N, R, H, Ca, Ce, I, A and D. scan() records each module's classes and whether each one is abstract (by its bases and decorators, read with ast). apply(g, remove=…) makes a copy of the graph with some corridors removed, so you can try a fix without touching the files.

🧪 Try it

python3 arch/demo.py modularity
python3 - <<'EOF'
import sys; sys.path.insert(0, "arch"); from analyze import scan, edges, floor, coupling, apply
cb = scan(); g = cb.imports
ca = sorted({a for a, b in edges(g) if floor(a) != "domain" and floor(b) == "domain"})
ce = sorted({a for a, b in edges(g) if floor(a) == "domain" and floor(b) != "domain"})
print("Ca (outside rooms that import domain):", ca)
print("Ce (domain rooms that import outside):", ce)
print(f"I = {len(ce)} / ({len(ca)} + {len(ce)}) = {len(ce) / (len(ca) + len(ce)):.2f}")
clean = apply(g, remove=[("domain.grades", "infra.db"), ("domain.timetable", "web.format")])
m = coupling(clean, cb.classes)["domain"]
print(f"without the 2 outward corridors: Ce={m['ce']} I={m['i']:.2f} A={m['a']:.2f} D={m['d']:.2f}")
EOF

✅ Verify — what you should see

modularity prints:

── per floor (component): N rooms, R corridors inside, H = (R+1)/N, Ca in, Ce out, I = Ce/(Ca+Ce), A abstract, D = |A+I-1|
   app     N=3 R=0 H=0.33 · Ca=2 Ce=3 I=0.60 · A=0.00 D=0.40
   domain  N=5 R=2 H=0.60 · Ca=5 Ce=2 I=0.29 · A=0.33 D=0.38
   infra   N=2 R=0 H=0.50 · Ca=3 Ce=2 I=0.40 · A=0.00 D=0.60
   main    N=1 R=0 H=1.00 · Ca=0 Ce=1 I=1.00 · A=0.00 D=0.00
   web     N=2 R=1 H=1.00 · Ca=2 Ce=1 I=0.33 · A=0.00 D=0.67

Your snippet prints:

Ca (outside rooms that import domain): ['app.enrol', 'app.fees_service', 'app.report_card', 'infra.db', 'infra.email']
Ce (domain rooms that import outside): ['domain.grades', 'domain.timetable']
I = 2 / (5 + 2) = 0.29
without the 2 outward corridors: Ce=0 I=0.00 A=0.33 D=0.67

🏁 What you just proved

The domain floor is the one everyone leans on (Ca = 5) — so it should be the most stable. Two corridors spoil that: domain.grades → infra.db and domain.timetable → web.format. Remove them and the domain's instability drops from 0.29 to 0.00. Notice what happened to D: it went up, from 0.38 to 0.67, because the domain is now perfectly stable but only one third abstract. That is why D is a hint: here the fix is right, and D says "stable and concrete" — which is normal for business rules that change only when the rules of the school change. The app floor has H = 0.33: its three rooms never import each other. A floor groups rooms by kind, not by job — lesson 05 groups them by department instead.

⚠️ Common mistakes

a utils or common module that everything imports — coincidental cohesion with a huge Ca
optimising a metric instead of reading it (splitting a module just to lower Ce)
a stable, heavily used component importing a volatile one (breaks "depend towards stability")
counting only direct imports and missing the long chains (the blast radius of lesson 01)
comparing numbers across tools without checking whether they count classes, modules or packages

🏭 In production

On a real project — tools that compute these numbers:

JDepend (Java) reports Ca, Ce, A, I and D per package — the same metrics.
NDepend (.NET) reports them per assembly, plus relational cohesion.
pydeps (Python) draws the import graph: pip install pydeps && pydeps yourapp --max-bacon 2.
import-linter (Python) does not compute metrics, but it enforces the rules you derive from them (lessons 03, 04 and 09).

A quick fan-in / fan-out count for any Python package, with only the standard library, is exactly what arch/analyze.py does — point scan() at your own code:

python3 -c 'import sys; sys.path.insert(0, "arch"); from analyze import scan, coupling
cb = scan("src", "yourapp"); print(coupling(cb.imports, cb.classes))'

🏭 Why this matters in production: record I and D per component in CI and plot them. A component whose instability creeps up while its fan-in grows is the next "nobody dares to touch it" part of your codebase.

⏭️ Next

Numbers per floor are useful. A rule about floors is better: which floor may call which? Layers and the dependency rule.

git checkout lesson-03-layers

← Previouswhat is architecture Next →layers

This page is the lesson's README from the lesson-02-modularity branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.