🏛️ शाळेच्या पद्धतीने software architecture शिका

# the 60-second wow — the floor plan, inspected:
git clone https://github.com/BaluRaut/learn-software-architecture-school.git && cd learn-software-architecture-school
python3 arch/demo.py               # 12 lessons: blast radius, layers, the hexagon, fitness functions, C4
python3 arch/analyze.py check      # the architecture tests — exit code 1 on the planted problems
python3 arch/test_arch.py          # 12 checks across the lessons

तुम्हाला काय दिसायला हवे (छाटलेले — यश असे दिसते):

═══ decisions ═══
── the building: arch/sample/schoolapp has 13 rooms (modules) and 24 corridors (imports), 187 lines
   blast radius = the rooms a change can ripple into (every room that reaches it through corridors):
   domain.admissions   8 of 12 rooms
   domain.ports        8 of 12 rooms
   domain.grades       4 of 12 rooms
   domain.timetable    0 of 12 rooms
   main                0 of 12 rooms
   repainting a room (a local variable) touches 1 room · moving a load-bearing wall (a port) touches 8 — THAT is architecture
── Katrina's three driving characteristics (the -ilities), each with a scenario and a price:
   modifiability  'a new department (the library) goes live within a term' · price: costs up-front structure
   testability    'the marks rules run in a test without a database' · price: needs ports and adapters (more types)
   availability   'report cards open on results day' · price: spare capacity, and fewer moving parts
   every characteristic you add costs another; pick the few that decide success

═══ 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
   domain is stable (I=0.29): 5 rooms outside lean on it · main is fully unstable (I=1.00): nobody imports it — both are fine
   app has H=0.33: its 3 rooms never talk to each other — a floor, not a department
   web has D=0.67: fairly stable but fully concrete — hard to change, nothing abstract to extend

═══ layers ═══
── floors, top to bottom: web → app → domain → infra · a room may import its own floor or any floor BELOW
   relaxed layering: 4 violations
     domain.timetable → web.format (upward)
     infra.db → domain.grades (upward)
     infra.db → domain.ports (upward)
     infra.email → domain.ports (upward)
   strict layering (only the floor directly below): 5 violations — adds app.enrol → infra.email (skips a floor)
   3 of the 4 are adapters importing the ports they implement — the classic stack calls that wrong; lesson 04 flips it

═══ hexagonal ═══
── rings: domain (core) ← app ← web + infra (adapters) · dependencies point INWARD only
   outward: app.enrol → infra.email
   outward: domain.grades → infra.db
   outward: domain.timetable → web.format
   the domain imports outside itself 2 times · outside libraries per room: domain.ports ['abc', 'typing'], infra.db ['sqlite3'], infra.email ['smtplib']
   to test domain.grades you must load 3 other rooms ['domain.admissions', 'domain.ports', 'infra.db']
   remove the 3 outward corridors (use the ports) → 1 ['domain.admissions'] · outward left: 0
   classic layers flagged infra → domain; the hexagon allows it and flags domain → infra instead

═══ ddd ═══
── departments (bounded contexts): admissions · grades · fees · timetable — each with its own meaning of 'student'
   in admissions a student is a form number, a name and a status
   in grades     a student is a roll number with marks in subjects
   in fees       a student is an account that owes money
── the context map, read from the code: 2 cross-department corridors
   fees → admissions: domain.fees imports Student from domain.admissions
   grades → admissions: domain.grades imports Student from domain.admissions
   grades → admissions: conformist today → an anti-corruption layer translates at the door
   fees → admissions: customer–supplier · both would break if admissions renamed Student.name

═══ styles ═══
── the same 4 departments in three styles (teaching assumptions: 1 ms and 1-in-1000 failure per network hop)
   monolith         1 deployable unit(s) · own deploys: no  · boundaries enforced by nothing (any room may import any room)
                    report card 0 hop(s) +0 ms 100.0% · pay fees 0 hop(s) +0 ms 100.0% · enrol 0 hop(s) +0 ms 100.0% · enrol needs one database transaction
   modular monolith 1 deployable unit(s) · own deploys: no  · boundaries enforced by a build-time check (lesson 09)
                    report card 0 hop(s) +0 ms 100.0% · pay fees 0 hop(s) +0 ms 100.0% · enrol 0 hop(s) +0 ms 100.0% · enrol needs one database transaction
   microservices    4 deployable unit(s) · own deploys: yes · boundaries enforced by the network (separate processes)
                    report card 2 hop(s) +2 ms 99.8% · pay fees 1 hop(s) +1 ms 99.9% · enrol 3 hop(s) +3 ms 99.7% · enrol needs a saga across services
   microservices buy independent deploys with hops, partial failure and sagas — the modular monolith keeps the boundaries without the network

═══ events ═══
── admissions publishes StudentAdmitted(Dipika, 5A) on the notice board → grades opens a mark sheet · fees opens an account · timetable assigns a class
   direct calls: admissions imports 3 departments · events: it imports 0 of them (only the event's shape) — a 4th listener needs no change to admissions
── CQRS: 3 marks written (72, 85, 90); the read model has applied 2 → average 78.5
   after catch-up it has applied 3 → average 82.33 · reads are fast, and eventually consistent

═══ data ═══
── fees needs a student's name 20 times; at tick 5 admissions renames name → full_name; ticks 10–12 admissions is down
   shared database  failed reads 15 · stale reads 0 · other teams' code broken by the rename 2
   API              failed reads  3 · stale reads 0 · other teams' code broken by the rename 0
   events           failed reads  0 · stale reads 2 · other teams' code broken by the rename 0
   shared DB: no call to admissions at run time, but total schema coupling · API: contract, but runtime coupling · events: own copy, but stale

═══ fitness ═══
── the fitness functions run on every push (python3 arch/analyze.py check)
   FAIL  no import cycles                         1 cycle(s): domain.grades ↔ infra.db
   FAIL  dependencies point inward                3 outward import(s)
   FAIL  the domain imports only the domain       2 leak(s)
   FAIL  departments do not import each other     2 cross-context import(s)
   PASS  fan-out ≤ 5 per room (main excluded)     max 4 (web.views)
   PASS  domain instability ≤ 0.5                 I = 0.29
   after removing the 5 planted corridors: 6/6 pass · CI exit code 0

═══ c4 ═══
── a C4 model as text (Structurizr DSL), 31 lines — the component arrows come from the code:
   app -> domain "imports (6)"
   app -> infra "imports (1)"
   domain -> infra "imports (1)"
   domain -> web "imports (1)"
   infra -> domain "imports (3)"
   web -> app "imports (3)"
   the wiki drawing is out of date: 3 arrows in the code are not on it: app → infra, domain → infra, domain → web
   after the fixes: 0 drift · generate the drawing from the code, or check it in CI

═══ adr ═══
── ATAM-lite: 5 scenarios, weight 1–3, each option scored 1–5 by the team
   modifiability  w=3 'add the library department within a term'
   operability    w=3 'run it with a team of 3'
   performance    w=2 'a report card in < 300 ms on results day'
   deployability  w=1 'release grades without redeploying fees'
   scalability    w=1 'survive 20× traffic on results day'
   modular monolith [4, 5, 5, 2, 3] → 42
   monolith         [2, 5, 5, 1, 3] → 35
   microservices    [4, 2, 3, 5, 5] → 34
   weights matter: microservices would win if deployability weighed 4 (not 1), or scalability 6 (not 1)
── the decision, written down as ADR-0007 (14 lines):
   # ADR-0007: A modular monolith for the school app
   Status: Accepted
   - one database transaction per request
   - no independent deploys yet
   - revisit if deployability weight reaches 4

═══ 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 2: /timetable     → 2/6 routes,  27% of traffic on the new wing
   step 3: /fees          → 3/6 routes,  42% of traffic on the new wing
   step 4: /enrol         → 4/6 routes,  47% of traffic on the new wing
   step 5: /marks/upload  → 5/6 routes,  55% of traffic on the new wing
   step 6: /report-card   → 6/6 routes, 100% of traffic on the new wing
── the whole picture: decide what is costly → rooms with few corridors → floors point one way → the core in the middle → departments with their own words → pick a style → notices, not calls → own your data → inspect every push → draw from the code → write the why → grow, don't rot

✅ done — the floor plan holds

🗺️ संपूर्ण चित्र — एक आकृती, पूर्ण कोर्स

संपूर्ण कोर्स एका कॅनव्हासवर. 4K आवृत्तीसाठी क्लिक करा.

🧱 भाग 1 — रचना (धडे 1–4)

एक git branch = एक कल्पना; branch 04 मध्ये धडे 01–04 आहेत. arch/analyze.py sample चे imports वाचतो — प्रत्येक run तेच आकडे छापतो.

🗂️ भाग 2 — सीमा आणि शैली (धडे 5–8)

भागांमधील रेषा कुठे काढायच्या, किती deployable units ठेवायची, आणि विभाग events व data कसे वाटून घेतात.

🔍 भाग 3 — निरोगी ठेवणे (धडे 9–12)

खरी राहणारी architecture: ती लागू करणाऱ्या tests, तिच्यापासून तयार होणारी आकृती, लिहून ठेवलेले निर्णय, आणि big-bang rewrite शिवाय बदल.

📐 धड्यांच्या आकृत्या — क्रमांक अनुसरा

प्रत्येक धडा एका क्रमांकित बॉक्स-आणि-बाण आकृतीत — स्वतंत्र पानावरही.