← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. प्रत्येक मोठ्या कल्पनेसाठी: आधी जीवन कसे होते, प्रामाणिक फायदे ✅ / तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

🏢 Classic layers vs ports and adapters — lessons 03, 04

⏮️ Before layers

Screens, rules and SQL in the same file; changing the database meant touching the business rules.

✅ फायदे

  • classic layers: simple to explain, one direction top to bottom
  • ports and adapters: the domain imports no infrastructure, so it tests in milliseconds with fakes

❌ तोटे

  • classic layers: the domain sits on the database, so adapters look like violations
  • ports and adapters: more interfaces and a composition root to wire them

👍 वापरा जेव्हा

  • classic layers for small CRUD apps with thin rules
  • ports and adapters where the business rules are the valuable, long-lived part

👎 दोनदा विचार करा जेव्हा

  • classic layers with the ORM model as the domain model for complex rules
  • a port per table with dozens of methods

🏘️ Modular monolith vs microservices — lesson 06

⏮️ Before modules

One big monolith where any room imported any room — a big ball of mud.

✅ फायदे

  • modular monolith: 0 network hops, one transaction, boundaries checked at build time
  • microservices: independent deploys and scaling per department

❌ तोटे

  • modular monolith: one deploy for everyone; one team's bad release affects all
  • microservices: hops, partial failure, sagas, far more operations work

👍 वापरा जेव्हा

  • modular monolith first, for most teams and products
  • microservices where a department truly needs its own deploy, scale or team

👎 दोनदा विचार करा जेव्हा

  • microservices for a small team to look modern
  • a modular monolith with no boundary checker (it decays)

📌 Direct calls vs events — lesson 07

⏮️ Before events

The admissions office walked to every other office to tell them about a new student.

✅ फायदे

  • direct calls: easy to follow, immediate answer
  • events: the publisher does not know its listeners; a new listener needs no change

❌ तोटे

  • direct calls: every new consumer edits the caller
  • events: the flow is harder to see; the event schema is a contract; read models lag

👍 वापरा जेव्हा

  • direct calls when you need the answer now
  • events for facts many departments react to

👎 दोनदा विचार करा जेव्हा

  • events for a request that needs a reply
  • direct calls fanning out to every department

🗄️ Shared database vs API vs events — lesson 08

⏮️ Before ownership

Every application read and wrote the same tables; nobody could rename a column.

✅ फायदे

  • shared DB: no runtime call; simple joins
  • API: the owner can change its tables freely
  • events: each reader keeps its own copy and works while the owner is down

❌ तोटे

  • shared DB: every table is an unagreed contract (a rename broke 2 teams in the lab)
  • API: fails while the owner is down
  • events: the copy is stale for the lag

👍 वापरा जेव्हा

  • APIs for data you need fresh
  • events for data you can read a little late
  • a versioned view if you must share one database

👎 दोनदा विचार करा जेव्हा

  • a table with two writers
  • CDC row changes published as the public contract

🔍 A rule on the wiki vs a fitness function — lesson 09

⏮️ Before fitness functions

Architecture rules lived in a document and in one senior engineer's head.

✅ फायदे

  • fitness function: every push is checked; drift is caught the day it happens
  • exception lists let you switch a rule on in an old codebase

❌ तोटे

  • rules must be written as code and kept up to date
  • coarse thresholds miss sharp problems (0.17 stayed under 0.5)

👍 वापरा जेव्हा

  • import rules, cycles and layer checks in the pull-request pipeline
  • thresholds you tighten over time

👎 दोनदा विचार करा जेव्हा

  • a strict rule with no exception list on a large old codebase
  • a nightly job nobody watches

🌳 Big-bang rewrite vs strangler fig — lesson 12

⏮️ Before the strangler fig

Freeze features, rewrite everything, switch over one weekend — and hope.

✅ फायदे

  • strangler fig: small, reversible steps; value delivered each step; can stop any time
  • big-bang: one clean design with no legacy constraints

❌ तोटे

  • strangler fig: two systems run side by side for a while; needs a facade
  • big-bang: months without features, a moving target, a risky cutover

👍 वापरा जेव्हा

  • strangler fig for live systems with users
  • branch by abstraction for the same idea inside one codebase

👎 दोनदा विचार करा जेव्हा

  • a strangler fig that never deletes the old path
  • a big-bang rewrite of a system people depend on daily