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

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

🌳 धडा 12 — Evolving architecture आणि संपूर्ण चित्र: वाढा, सडू नका

📍 तुम्ही इथे आहात: 12 पैकी धडा 12 · मागचा: lesson-11-adrs · पुढचा: 🎓 तुमचा कोर्स पूर्ण झाला

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

धडे 01–11, आणि काळ. Architecture हे पहिल्या term चे चित्र नाही; अनेक terms नंतर इमारत जी बनते ते architecture. काळानुसार सडणे कसे मोजायचे — cycles, propagation cost आणि बाहेर जाणारे imports — आणि मोठी इमारत वापरात असतानाच strangler fig ने कशी बदलायची: समोर एक facade, एका वेळी एक route हलवला जातो, आणि शेवटी जुनी इमारत निवृत्त होते. TERMS, strangler() arch/models.py मध्ये, propagation_cost() आणि cycles() arch/analyze.py मध्ये, evolve() arch/demo.py मध्ये.

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

प्रत्येक term ला शाळेतली गर्दी थोडी वाढते. 🏫 बांधकाम करणारे इथे एक दार, तिथे एक shortcut जोडतात — त्या त्या दिवशी प्रत्येक योग्यच वाटते. काही terms नंतर, कोणत्याही खोलीतून जवळजवळ कोणत्याही खोलीत चालत जाता येते, अनेकदा गोल गोल फिरत. अर्ध्या शाळेला त्रास दिल्याशिवाय कोणीही दुरुस्तीसाठी एक खोली बंद करू शकत नाही. यालाच big ball of mud (चिखलाचा गोळा) म्हणतात.

कतरिना प्रत्येक term ला इमारत मोजते — किती वर्तुळे, प्रत्येक खोली किती खोल्यांपर्यंत पोहोचू शकते — म्हणजे चिखल येताना तिला फक्त जाणवत नाही, तर दिसतो.

आणि इमारतीचा एखादा भाग दुरुस्त करण्यापलीकडे जुना झाला तर? ती सोमवारी सगळे पाडून टाकत नाही. ती जुन्या इमारतीशेजारी नवीन दालन बांधते, पुढच्या दारावर एक स्वागतिका बसवते, आणि एका वेळी एक वर्ग हलवते: "timetable चे प्रश्न — कृपया नवीन दालनात." शेवटचा वर्ग हलला की जुनी इमारत पाडली जाते. जुन्या झाडाभोवती वाढत वाढत स्वतःच्या पायावर उभ्या राहणाऱ्या strangler fig 🌳 झाडासारखे.

🗺️ आकृती

flowchart LR
    subgraph terms["📈 the building over four terms"]
      t1["term 1 · first plan<br/>0 cycles · 24.3%"] --> t2["term 2 · as shipped<br/>1 cycle · 31.4%"]
      t2 --> t3["term 3 · exam rush<br/>4 cycles · 49.7%"]
      t3 --> t4["term 4 · checks + library<br/>0 cycles · 22.2%"]
    end
    subgraph fig["🌳 strangler fig"]
      door["🛎️ facade / router"] -->|"moved routes"| newwing["🆕 new wing"]
      door -->|"the rest"| old["🏚️ old building"]
    end

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

❓ काय

Architecture erosion (drift) — ठरवलेली रचना आणि code यांतील अंतर एका वेळी एका छोट्या बदलाने वाढत जाते.
Big ball of mud — Brian Foote आणि Joseph Yoder (1997): "a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle". ही कोणी निवडलेली शैली नाही — कोणीच विरोध करत नाही तेव्हा आपोआप होणारी स्थिती.
Cycle (tangle) — एकमेकांपर्यंत पोहोचणाऱ्या modules चा गट (strongly connected component). इतरांशिवाय त्यातले एक समजून घेता, test करता किंवा वेगळे करता येत नाही. Lab असे गट आणि सर्वात मोठ्या गटाचा आकार मोजते.
Propagation cost — Alan MacCormack, John Rusnak आणि Carliss Baldwin (2006): सर्व (module, module) जोड्यांपैकी अशा जोड्यांचा वाटा ज्यात पहिला dependencies मधून दुसऱ्यापर्यंत पोहोचतो, प्रत्येक module स्वतःपर्यंत पोहोचतो असे धरून. एखादा बदल सरासरी किती दूर पसरू शकतो याचा हा अंदाज आहे. कमी असणे चांगले; वाढता कल हा धोक्याचा इशारा.
Evolutionary architecture — मार्गदर्शित, टप्प्याटप्प्याने बदलाला आधार देणारी architecture (धडा 09 मधल्या fitness functions हेच मार्गदर्शक).
Strangler fig pattern — Martin Fowler (2004): legacy system हळूहळू बदलणे. एक facade (proxy, gateway किंवा router) प्रत्येक route एकतर जुन्या system कडे किंवा नव्याकडे पाठवतो; एका वेळी एक route हलवा; काहीच उरले नाही की जुने system निवृत्त करा.
Branch by abstraction — हीच कल्पना एकाच codebase च्या आत: जुन्या code समोर एक interface (port, धडा 04) ठेवा, त्यामागे नवीन implementation बांधा, त्याकडे वळा, आणि जुने delete करा.

🤔 का

कारण कोणताही आराखडा चार terms न बदलता टिकत नाही — आणि big-bang rewrites अनेकदा अपयशी ठरतात, महिनोन्महिने feature चे काम थांबवतात, आणि त्यांना सतत हलणारे लक्ष्य गाठावे लागते. काळानुसार मोजल्याने "code वाईट वाटतोय" याचे रूपांतर दाखवता येणाऱ्या कलात होते. Strangler fig "पुन्हा लिहा" चे रूपांतर अनेक छोट्या, मागे घेता येणाऱ्या पायऱ्यांत करते, प्रत्येक पायरी मूल्य देते आणि प्रत्येकीवर थांबता येते.

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

arch/models.py मधले TERMS sample च्या चार snapshots चे वर्णन करते: term 1 म्हणजे धड्यांतील fixes लागू केलेला आराखडा, term 2 म्हणजे दिलेला code, term 3 exam-rush चे पाच shortcuts जोडते, term 4 fixes लागू करते आणि एक library विभाग जोडते (LIBRARY: दोन नवीन खोल्या, पाच नवीन मार्गिका, सगळ्या आतल्या दिशेने). evolve() प्रत्येकासाठी छापते: खोल्या, मार्गिका, cycles (आणि सर्वात मोठा), propagation_cost(), बाहेर जाणारे imports आणि किती मजले एकमेकांत गुंतले आहेत. strangler(order) प्रत्येक पायरीला एक route हलवते आणि नवीन दालन आता traffic चा (TRAFFIC, एक शिकवण्यासाठीचे गृहीतक) किती वाटा हाताळते त्याची बेरीज करते.

🧪 करून पाहा

python3 arch/demo.py evolve
python3 - <<'EOF'
import sys; sys.path.insert(0, "arch"); from analyze import scan, apply, cycles
from models import TERMS, strangler
g = scan().imports
rush = apply(g, add=TERMS[2][1])
for c in cycles(rush): print("tangled together:", ", ".join(c))
for k, r, n, pct in strangler(("/report-card", "/timetable", "/fees", "/marks/upload", "/enrol", "/admin")):
    print(f"busiest first, step {k}: {r:<14} {pct:>3}% of traffic on the new wing")
EOF
python3 arch/demo.py
python3 arch/test_arch.py

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

evolve हे छापते:

── the building over four terms: rooms · corridors · cycles (largest) · propagation cost · outward imports · floors tangled
   term 1 · the first plan          13 · 19 · 0 (0) · 24.3% · 0 · floors tangled 0
   term 2 · as shipped              13 · 24 · 1 (2) · 31.4% · 3 · floors tangled 4
   term 3 · exam rush               13 · 29 · 4 (3) · 49.7% · 3 · floors tangled 4
   term 4 · checks + a library wing 15 · 24 · 0 (0) · 22.2% · 0 · floors tangled 0
── the strangler fig: a facade sends each route to the old building or the new wing, one route at a time
   step 1: /admin         → 1/6 routes,   2% of traffic on the new wing
   step 6: /report-card   → 6/6 routes, 100% of traffic on the new wing

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

tangled together: domain.grades, domain.ports, infra.db
tangled together: app.enrol, infra.email
tangled together: domain.admissions, domain.fees
tangled together: domain.timetable, web.format
busiest first, step 1: /report-card    45% of traffic on the new wing
busiest first, step 2: /timetable      70% of traffic on the new wing
busiest first, step 3: /fees           85% of traffic on the new wing
busiest first, step 4: /marks/upload   93% of traffic on the new wing
busiest first, step 5: /enrol          98% of traffic on the new wing
busiest first, step 6: /admin         100% of traffic on the new wing

पूर्ण demo ✅ done — the floor plan holds ने संपतो, आणि tests 12/12 passed ने.

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

Exam rush मधल्या योग्य दिसणाऱ्या पाच shortcuts नी इमारत 1 cycle वरून 4 वर नेली, आणि propagation cost 31.4% वरून 49.7% वर — सरासरी, एक खोली आता जवळजवळ अर्ध्या इमारतीपर्यंत पोहोचते. Ring नियम परवानगी देतो असे shortcuts सुद्धा (आतल्या दिशेने, किंवा एकाच ring च्या आत, म्हणून बाहेर जाणाऱ्या imports ची संख्या 3 वरच राहिली) नवीन वर्तुळे पूर्ण करत होते, जसे domain.ports ने domain.grades import करणे: दिशेबद्दलचा नियम हा cycles बद्दलचा नियम नसतो, म्हणूनच धडा 09 दोन्ही तपासतो. Term 4 वाढला — 15 खोल्या, नवीन library विभाग — आणि तरीही पहिल्या आराखड्यापेक्षा स्वच्छ संपला (22.2%, 0 cycles): वाढ ही समस्या नाही, पहारा नसलेली वाढ ही समस्या आहे. Strangler चा क्रम ही सुद्धा खरी निवड आहे: /admin आधी हलवल्याने तुम्ही शिकत असताना traffic चा फक्त 2% धोक्यात येतो; /report-card आधी हलवल्याने एकाच पायरीत 45% नवीन दालनावर येतो.

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

"switch-over weekend" असलेले big-bang rewrite
facade नसलेले strangler fig — मग routes हलवायला एकच जागा उरत नाही
जुना मार्ग कधीच delete न करणे, त्यामुळे दोन systems कायम चालवत राहणे
फक्त एकदा, सुरुवातीला मोजणे — कोणत्याही एका आकड्यापेक्षा कल जास्त महत्त्वाचा
प्रत्येक cycle सारखाच मानणे — एका विभागातल्या दोन खोल्यांचा गुंता, एकमेकांत गुंतलेल्या मजल्यांपेक्षा खूपच स्वस्त असतो

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

खऱ्या project वर — strangler facade NGINX config इतका साधा असू शकतो: हलवलेले routes नवीन दालनाकडे, बाकी सगळे जुन्या इमारतीकडे:

upstream old_building { server legacy.internal:8080; }
upstream new_wing     { server school-v2.internal:8080; }
server {
    listen 80;
    location /admin     { proxy_pass http://new_wing; }
    location /timetable { proxy_pass http://new_wing; }
    location /          { proxy_pass http://old_building; }   # everything not moved yet
}

प्रत्येक build वर रचनेचे metrics नोंदवा, म्हणजे प्रत्येक term चा आलेख काढता येईल:

python3 arch/analyze.py | head -1 >> docs/architecture/metrics.log

Cloud मध्ये हाच facade अनेकदा API gateway किंवा load balancer rule असतो (path-based routing); एकाच codebase च्या आत, तो दोन adapters असलेला port आणि त्यांच्यात बदल करणारा feature flag असतो.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: तीन आकडे निवडा — cycles, propagation cost, नियमांची उल्लंघने — प्रत्येक merge वर ते नोंदवा, आणि महिन्यातून एकदा कल पाहा. चिखल हळूहळू साचतो; तो लक्षात येणेही हळूच होते.

🎓 इमारतीचा नकाशा टिकून राहतो

Architecture म्हणजे बदलायला महाग असलेले निर्णय → मोजलेल्या, थोड्या आणि आवश्यक मार्गिका असलेल्या खोल्या → जिने एकाच दिशेने जाणारे मजले → मध्यभागी, दारे बाहेरच्या बाजूला असलेली नियमपुस्तिका → आपापले शब्द असलेले विभाग → कॅम्पसच्या आधी भिंती असलेली एकच इमारत → मार्गिकेतून फेऱ्यांऐवजी फलकावर सूचना → प्रत्येक कपाटाला एकच मालक → प्रत्येक push वर एक निरीक्षक → इमारतीतूनच छापलेला इमारतीचा नकाशा → "का" ची नोंदवही → आणि दर term ला वाढूनही चिखल न होणारी इमारत. तुम्ही फक्त software architecture शिकला नाहीत — तुम्ही कोणताही codebase उघडू शकता, त्याच्या खोल्या आणि मार्गिका काढू शकता, आणि कोणते निर्णय महाग आहेत, तो कोणते नियम मोडतो, आणि आधी काय दुरुस्त करायचे ते सांगू शकता. 🏛️📐🎓

⏭️ पुढे

इतर शाळा. System Design शाळा caches, queues आणि shards सह distributed systems design करते; Distributed Systems शाळा machines मध्ये काय बिघडते ते समजावते; API शाळा विभागांमधले करार design करते; CI/CD शाळा fitness functions चालवते; School portal मध्ये बाकी सगळे आहे.

git checkout main
python3 arch/demo.py     # one last run, for fun

🌳 Lesson 12 — Evolving architecture & the whole picture: grow, don't rot

📍 You are here: Lesson 12 of 12 · Previous: lesson-11-adrs · Next: 🎓 you're done

📦 What's in this branch

Lessons 01–11, plus time. Architecture is not a picture from the first term; it is what the building becomes after many terms. How to measure rot over time — cycles, propagation cost and outward imports — and how to change a big building while it is in use with the strangler fig: a facade in front, routes moved one at a time, the old building retired at the end. TERMS, strangler() in arch/models.py, propagation_cost() and cycles() in arch/analyze.py, evolve() in arch/demo.py.

🧒 Explain like I'm 5

Every term, the school gets a little busier. 🏫 Builders add a door here, a shortcut there — each one sensible on the day. After a few terms, you can walk from any room to almost any other room, often in circles. Nobody can close one room for repairs without disturbing half the school. That is a big ball of mud.

Katrina measures the building every term — how many circles, how many rooms each room can reach — so she can see the mud coming, not just feel it.

And when a part of the building is too old to fix? She does not knock it all down on a Monday. She builds a new wing next to the old building, puts a receptionist at the front door, and moves one class at a time: "timetable questions — new wing, please." When the last class has moved, the old building comes down. Like a strangler fig 🌳 tree that grows around an old tree until it can stand on its own.

🗺️ Diagram

flowchart LR
    subgraph terms["📈 the building over four terms"]
      t1["term 1 · first plan<br/>0 cycles · 24.3%"] --> t2["term 2 · as shipped<br/>1 cycle · 31.4%"]
      t2 --> t3["term 3 · exam rush<br/>4 cycles · 49.7%"]
      t3 --> t4["term 4 · checks + library<br/>0 cycles · 22.2%"]
    end
    subgraph fig["🌳 strangler fig"]
      door["🛎️ facade / router"] -->|"moved routes"| newwing["🆕 new wing"]
      door -->|"the rest"| old["🏚️ old building"]
    end

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

❓ What

Architecture erosion (drift) — the gap between the intended structure and the code grows, one small change at a time.
Big ball of mud — Brian Foote and Joseph Yoder (1997): "a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle". Not a style anyone picks — the default when nobody pushes back.
Cycle (tangle) — a group of modules that all reach each other (a strongly connected component). You cannot understand, test or split one without the others. The lab counts the groups and the size of the largest.
Propagation cost — Alan MacCormack, John Rusnak and Carliss Baldwin (2006): the share of all (module, module) pairs where the first reaches the second through dependencies, each module counted as reaching itself. It estimates how far a change can ripple, on average. Lower is better; a rising trend is the warning sign.
Evolutionary architecture — architecture that supports guided, incremental change (the fitness functions of lesson 09 are the guide).
Strangler fig pattern — Martin Fowler (2004): replace a legacy system gradually. A facade (a proxy, gateway or router) sends each route either to the old system or the new one; move routes one at a time; retire the old system when nothing is left.
Branch by abstraction — the same idea inside one codebase: put an interface (a port, lesson 04) in front of the old code, build the new implementation behind it, switch over, delete the old one.

🤔 Why

Because no plan survives four terms unchanged — and big-bang rewrites fail often, stop feature work for months, and have to hit a moving target. Measuring over time turns "the code feels worse" into a trend you can show. The strangler fig turns "rewrite it" into many small, reversible steps, each one delivering value and each one able to stop.

🔧 How (in this repo)

TERMS in arch/models.py describes four snapshots of the sample: term 1 is the plan with the lesson fixes applied, term 2 is the shipped code, term 3 adds five exam-rush shortcuts, term 4 applies the fixes and adds a library department (LIBRARY: two new rooms, five new corridors, all pointing inward). evolve() prints, for each: rooms, corridors, cycles (and the largest), propagation_cost(), outward imports and how many floors are tangled together. strangler(order) moves one route per step and adds up the share of traffic (TRAFFIC, a teaching assumption) the new wing now serves.

🧪 Try it

python3 arch/demo.py evolve
python3 - <<'EOF'
import sys; sys.path.insert(0, "arch"); from analyze import scan, apply, cycles
from models import TERMS, strangler
g = scan().imports
rush = apply(g, add=TERMS[2][1])
for c in cycles(rush): print("tangled together:", ", ".join(c))
for k, r, n, pct in strangler(("/report-card", "/timetable", "/fees", "/marks/upload", "/enrol", "/admin")):
    print(f"busiest first, step {k}: {r:<14} {pct:>3}% of traffic on the new wing")
EOF
python3 arch/demo.py
python3 arch/test_arch.py

✅ Verify — what you should see

evolve prints:

── the building over four terms: rooms · corridors · cycles (largest) · propagation cost · outward imports · floors tangled
   term 1 · the first plan          13 · 19 · 0 (0) · 24.3% · 0 · floors tangled 0
   term 2 · as shipped              13 · 24 · 1 (2) · 31.4% · 3 · floors tangled 4
   term 3 · exam rush               13 · 29 · 4 (3) · 49.7% · 3 · floors tangled 4
   term 4 · checks + a library wing 15 · 24 · 0 (0) · 22.2% · 0 · floors tangled 0
── the strangler fig: a facade sends each route to the old building or the new wing, one route at a time
   step 1: /admin         → 1/6 routes,   2% of traffic on the new wing
   step 6: /report-card   → 6/6 routes, 100% of traffic on the new wing

Your snippet prints:

tangled together: domain.grades, domain.ports, infra.db
tangled together: app.enrol, infra.email
tangled together: domain.admissions, domain.fees
tangled together: domain.timetable, web.format
busiest first, step 1: /report-card    45% of traffic on the new wing
busiest first, step 2: /timetable      70% of traffic on the new wing
busiest first, step 3: /fees           85% of traffic on the new wing
busiest first, step 4: /marks/upload   93% of traffic on the new wing
busiest first, step 5: /enrol          98% of traffic on the new wing
busiest first, step 6: /admin         100% of traffic on the new wing

The full demo ends with ✅ done — the floor plan holds, and the tests with 12/12 passed.

🏁 What you just proved

Five sensible-looking shortcuts in the exam rush took the building from 1 cycle to 4, and propagation cost from 31.4% to 49.7% — on average, a room now reaches about half the building. Even shortcuts the ring rule allows (inward, or inside one ring, so the outward-import count stayed at 3) closed new circles, like domain.ports importing domain.grades: a rule about direction is not a rule about cycles, which is why lesson 09 checks both. Term 4 grew — 15 rooms, a new library department — and still ended cleaner than the first plan (22.2%, 0 cycles): growth is not the problem, unguarded growth is. The strangler order is a real choice too: moving /admin first puts only 2% of traffic at risk while you learn; moving /report-card first puts 45% on the new wing in one step.

⚠️ Common mistakes

a big-bang rewrite with a "switch-over weekend"
a strangler fig with no facade — then there is no single place to move routes
never deleting the old path, so you run two systems forever
measuring once, at the start — trends matter more than any single number
treating every cycle the same — a two-room tangle inside one department is far cheaper than floors tangled together

🏭 In production

On a real project — a strangler facade can be as simple as an NGINX config: moved routes go to the new wing, everything else to the old building:

upstream old_building { server legacy.internal:8080; }
upstream new_wing     { server school-v2.internal:8080; }
server {
    listen 80;
    location /admin     { proxy_pass http://new_wing; }
    location /timetable { proxy_pass http://new_wing; }
    location /          { proxy_pass http://old_building; }   # everything not moved yet
}

Record the structure metrics on every build so you can plot them per term:

python3 arch/analyze.py | head -1 >> docs/architecture/metrics.log

In the cloud, the same facade is often an API gateway or a load balancer rule (path-based routing); inside one codebase, it is a port with two adapters and a feature flag to switch between them.

🏭 Why this matters in production: pick three numbers — cycles, propagation cost, rule violations — record them on every merge, and look at the trend once a month. Mud is slow; so is noticing it.

🎓 The floor plan holds

Architecture is the decisions that are costly to change → rooms with few, needed corridors, measured → floors whose stairs go one way → the rule book in the middle with its doors facing out → departments with their own words → one building with walls before a campus → notices on the board instead of walks down the corridor → every cupboard with one owner → an inspector on every push → a floor plan printed from the building → a logbook of why → and a building that grows every term without turning into mud. You didn't just learn software architecture — you can open any codebase, draw its rooms and corridors, and say which decisions are expensive, which rules it breaks, and what to fix first. 🏛️📐🎓

⏭️ Next

The other schools. The System Design school designs distributed systems with caches, queues and shards; the Distributed Systems school explains what goes wrong between machines; the API school designs the contracts between departments; the CI/CD school runs the fitness functions; the School portal has the rest.

git checkout main
python3 arch/demo.py     # one last run, for fun

← Previousadrs Finished! Take the quiz →check what stuck

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