परतों से विशेषताओं तक: वर्टिकल स्लाइस का जन्म क्यों हुआ? (Vertical Slice From Layers To Features)

आइए पहले CRUD और परतों को दोष न दें

लेयर्ड आर्किटेक्चर कई छोटे और मध्यम आकार के सिस्टम के लिए एक अच्छी शुरुआत है। नियंत्रक, एप्लिकेशन सेवा, रिपॉजिटरी और डेटा एक्सेस का पृथक्करण; यह टीम को एक सामान्य तकनीकी भाषा प्रदान करता है। समस्या इन परतों के अस्तित्व की नहीं है। समस्या यह है कि एक एकल उपयोगकर्ता का अनुरोध समय के साथ सभी परतों तक फैल जाता है और प्रत्येक परिवर्तन एक समन्वय कार्य में बदल जाता है।

एक दिन, एक साधारण सा अनुरोध आता है: ऑर्डर में एक डिलीवरी नोट जोड़ने के लिए।```text Controller → Request / DTO → Service → Validator → Repository → Mapping → Test doubles → Tests

## पहले उल्लेख पर अवधारणाएँ```text
📦 Vertical Slice
Bir kullanıcı niyetini request'ten veri kaydına ve teste kadar tek sınırda tutan uçtan uca özellik birimi.

📦 Davranışın yerelliği
Bir davranışı anlamak veya değiştirmek için gereken kodun birbirine fiziksel olarak yakın olması.

📦 Temporal DRY
Bugün benzer görünen kodun, yarın aynı sebeple değişip değişmeyeceğini sorgulayan DRY yaklaşımı.

📦 Wrong abstraction
Sadece tekrar var diye erken paylaşılan; zamanla farklı ihtiyaçları birbirine bağlayan soyutlama.
```वर्टिकल स्लाइस परतों को प्रतिबंधित नहीं करता है। सुविधा के भीतर तकनीकी अंतर रखता है; सुविधा की बाहरी सीमा उपयोगकर्ता के इरादे, व्यावसायिक नियम और स्वामित्व द्वारा निर्धारित की जाती है।

## कहानी: परतें कब धीमी होती हैं?

पहला दिन `CreateOrder` छोटा है। एक नियंत्रक, एक सेवा और एक भंडार पर्याप्त लगता है। फिर स्टॉक नियंत्रण, अभियान नियम, डिलीवरी प्राथमिकता और ऑडिट रिकॉर्ड जोड़ा जाता है। जब प्रत्येक विशेषता एक ही `OrderService` में आती है, तो सिस्टम में सबसे जोखिम भरी फ़ाइल सबसे अधिक उपयोग की जाने वाली फ़ाइल बन जाती है।```text
Yeni özellik
  → ortak Service'e dokunur
  → ilgisiz testleri etkiler
  → farklı ekiplerin release'ini bekler
```सीआरयूडी टूटा नहीं है. मॉडल और एप्लिकेशन परत की जिम्मेदारी अलग-अलग होती है। वर्टिकल स्लाइस का प्रश्न है: कौन सा व्यावसायिक इरादा इस व्यवहार को बदल रहा है?

## क्षैतिज और ऊर्ध्वाधर संगठन

| कसौटी | परत केंद्रित | फ़ीचर केंद्रित |
| --- | --- | --- |
| संगठनात्मक धुरी | तकनीकी भूमिका | उपयोगकर्ता अभिप्राय/विशेषता |
| विनिमय की इकाई | एकाधिक परतों पर फ़ाइल | एकल सुविधा सीमा |
| कोड शेयरिंग | प्रारंभिक सामान्य सेवा प्रवृत्ति | सिद्ध साझेदारी |
| नेविगेशन | नियंत्रक → सेवा → भंडार | फ़ीचर → अनुरोध → हैंडलर → परीक्षण |
| त्रुटि प्रभाव | सामान्य परत के माध्यम से प्रचारित किया जा सकता है | फीचर इसके बॉर्डर पर अधिक दृश्यमान रहता है |```text
❌ Controllers / Services / Repositories
    → OrdersController
    → OrderService
    → OrderRepository

✓ Features / Orders / CreateOrder
    → Request
    → Validator
    → Handler
    → Response
    → Tests
```यह अंतर सिर्फ फ़ोल्डर नाम का नहीं है. यह किसी परिवर्तन को खोजने, समझने, परीक्षण करने और वापस लाने की लागत को प्रभावित करता है। यहां तक ​​​​कि अगर किसी सुविधा के भीतर खोज की लागत फ़ाइलों की संख्या `n` के लिए सबसे खराब स्थिति में O(n) बनी रहती है, तो संबंधित कोड को व्यवस्थित करने से गलत निर्देशिकाओं में खोज और मानसिक स्विच की संख्या कम हो जाती है।

## स्क्रीमिंग आर्किटेक्चर: निर्देशिका संरचना को क्या बताना चाहिए?

यदि किसी प्रोजेक्ट को खोलने पर सबसे पहले दिखाई देने वाले फ़ोल्डर `Controllers`, `Services` और `Infrastructure` हैं; सिस्टम तकनीकी उपकरण समझाता है। `Orders`, `Catalog`, `Billing` और `Returns` व्यवसाय क्षेत्र का वर्णन करते हैं। इसे उत्पाद के इरादे को उजागर करना चाहिए, न कि वास्तुशिल्प ढांचे को।

`CancelOrder` परिवर्तन में, डेवलपर व्यवहार के हैंडलर, सत्यापन, प्रतिक्रिया और परीक्षण को एक ही स्थान पर पाता है; यह टीम के नए सदस्य के लिए सीखने की प्रक्रिया को भी छोटा कर देता है। हालाँकि, फीचर फ़ोल्डर कोई छोटा मोनोलिथ नहीं है जहाँ सब कुछ सार्वजनिक है। प्रवेश बिंदु खुला रहता है; फीचर में विवरण छिपा हुआ है।

## सामंजस्य, एनकैप्सुलेशन और रणनीतिक दोहराव

एक स्लाइस को दूसरे स्लाइस के आंतरिक कार्यान्वयन का पता नहीं होना चाहिए। संयुक्त व्यवहार को साझा किया जाना चाहिए यदि यह वास्तव में स्थिर है और कम से कम कई स्वतंत्र आवश्यकताओं के कारण एक ही कारण से बदलता है। अन्यथा, `Shared` फ़ोल्डर बिना किसी दृश्य सीमा के एक नई परत बन जाता है।```text
CreateOrder
  → Order aggregate'e komut verir
  → local transaction'ı tamamlar
  → response üretir

CancelOrder
  → kendi kurallarını uygular
  → CreateOrder'ın handler'ını çağırmaz
```इस दृष्टिकोण में, नकल कभी-कभी सही कीमत होती है। यदि अलग-अलग व्यावसायिक निर्णयों के कारण कोड के दो समान टुकड़े बदलने जा रहे हैं, तो उन्हें जल्दी विलय करने से भविष्य में प्रत्येक परिवर्तन को O(k) निर्भर सुविधाओं में प्रचारित किया जा सकता है।

## संक्रमण संकेत

वर्टिकल स्लाइस पर स्विच करने के लिए केवल आधुनिक दिखना ही पर्याप्त नहीं है। निम्नलिखित संकेत एक साथ होने पर निवेश रिटर्न मिलता है:

1. जब एक साधारण अनुरोध को लगातार कई परतों में परिवर्तन की आवश्यकता होती है।
2. सामान्य सेवाओं में छोटे परिवर्तन असंबंधित सुविधा परीक्षणों को तोड़ देते हैं।
3. यदि मॉक-सघन परीक्षण व्यवहार को संरक्षित करते हैं लेकिन आंतरिक कॉल ऑर्डर को नहीं।
4. यदि टीम को यह पता लगाने में परेशानी हो रही है कि व्यावसायिक नियम किस फ़ाइल में है।
5. यदि विभिन्न सुविधाओं के मालिकों और वितरण लय को अलग कर दिया जाए।

इन सीमाओं को दस्तावेज़ीकरण के साथ नहीं छोड़ा जाना चाहिए। .NET में वास्तुशिल्प परीक्षणों के साथ, आप जांच सकते हैं कि एक सुविधा किसी अन्य सुविधा के आंतरिक विवरण पर निर्भर नहीं है। नियम की लागत संकलन या परीक्षण चरण के दौरान ओ (निर्भरता) स्कैनिंग है; लाभ यह है कि उल्लंघन उत्पादन तक पहुंचने से पहले ही प्रकट हो जाता है।

## डीडीडी और सीक्यूआरएस से इसका संबंध

वर्टिकल स्लाइस एप्लिकेशन को व्यवस्थित करता है। DDD वर्णन करता है कि व्यवसाय के नियम और भाषा कहाँ रहते हैं। दूसरी ओर, CQRS, उपयोग के मामले के कमांड और क्वेरी पक्षों पर प्रवाह को अलग कर सकता है। ये प्रतिस्पर्धी नहीं हैं, बल्कि निर्णयों की विभिन्न परतें हैं।```text
Feature boundary  → Vertical Slice
Consistency rule  → DDD Aggregate
Read / write flow → CQRS
Deployment unit   → Modular monolith veya microservice
```मॉड्यूलर मोनोलिथ के भीतर फीचर सीमा को मान्य करने से पहले माइक्रोसर्विस लागत का भुगतान किए बिना स्वतंत्रता दावे का परीक्षण करने की अनुमति मिलती है।

## मिलान जो झूठा आत्मविश्वास पैदा करता है```text
❌ Vertical Slice = klasörleri yeniden adlandırmak
✓ Kullanıcı niyeti, davranış ve sahipliği aynı sınırda tutmaktır.

❌ DRY = her benzer kodu paylaşmak
✓ Aynı nedenle değişen kodu paylaşmaktır.

❌ Handler = tüm iş kuralları
✓ Handler orkestrasyon yapar; domain kuralları uygun domain modelinde yaşar.

❌ Vertical Slice = mikroservis
✓ Önce modüler monolith içinde doğrulanabilen application boundary'dir.

❌ Shared = ücretsiz yeniden kullanım
✓ Shared, sürümleme ve koordinasyon maliyeti de getirir.

निर्णय चेकलिस्ट

1. क्या यह कोड समान उपयोगकर्ता इरादे के कारण बदल रहा है?
2. क्या किसी फीचर का अनुरोध, सत्यापन, हैंडलर, प्रतिक्रिया और परीक्षण एक साथ मौजूद हो सकते हैं?
3. क्या मैं किसी अन्य सुविधा की आंतरिक कक्षा तक पहुँच के बिना अपनी ज़रूरतें पूरी कर सकता हूँ?
4. क्या यह सामान्य अमूर्तता कम से कम तीन स्वतंत्र स्थानों पर एक ही कारण से बदलती है?
5. क्या समग्र नियम और अनुप्रयोग ऑर्केस्ट्रेशन अलग-अलग हैं?
6. क्या मॉड्यूलर मोनोलिथ के भीतर फीचर सीमा वास्तुशिल्प परीक्षणों द्वारा संरक्षित है?
7. क्या परिवर्तन के बाद त्रुटि प्रभाव, परीक्षण कवरेज और रोलबैक पथ दिखाई दे रहे हैं?

लक्ष्य अधिक फ़ोल्डर बनाना नहीं है. लक्ष्य किसी व्यवहार को बदलने के लिए आवश्यक निर्णय और कोड सतह को कम करना है।

इस लेख से आपको क्या याद रखना चाहिए

1. स्तरित वास्तुकला खराब नहीं है; हालाँकि, जब विनिमय की इकाई को परतों में फैलाया जाता है, तो समन्वय लागत बढ़ जाती है।
2. वर्टिकल स्लाइस तकनीकी भूमिकाओं के बजाय उपयोगकर्ता के इरादे और व्यवहार पर कोड केंद्रित करता है।
3. रणनीतिक दोहराव मिथ्या अमूर्तन से सस्ता हो सकता है।
4. लंबवत टुकड़ा; डीडीडी एक एप्लिकेशन संगठन निर्णय है जो सीक्यूआरएस और मॉड्यूलर मोनोलिथ के साथ मिलकर काम करता है।

वर्टिकल स्लाइस का उद्देश्य फाइलों को लंबवत रूप से व्यवस्थित करना नहीं है; परिवर्तन के प्रभाव को सही सुविधा सीमा पर रखना है।

अगले भाग में, हम जांच करेंगे कि एक स्लाइस अनुरोध, सत्यापन, हैंडलर, मैपिंग और परीक्षणों के साथ अंदर से कैसे काम करता है।