एक लंबवत टुकड़ा अंदर से कैसे काम करता है? (Vertical Slice Inside Out)

30 सेकंड में सारांश

जब कोई HTTP अनुरोध सिस्टम पर आता है, तो यह वास्तव में किसी एक विधि पर नहीं जाता है। सबसे पहले, इसे बाहरी सीमा से आयात किया जाता है, सत्यापित किया जाता है, प्राधिकरण नियंत्रण के माध्यम से पारित किया जाता है, यदि आवश्यक हो, तो लेनदेन खोला जाता है, डोमेन नियम लागू किया जाता है, डेटा रिकॉर्ड किया जाता है, ईवेंट सुरक्षित किया जाता है और रीडिंग पक्ष अपडेट किया जाता है।

वर्टिकल स्लाइस इस यात्रा को एकल उपयोगकर्ता के इरादे के इर्द-गिर्द आयोजित करता है।```text HTTP Request | v Endpoint / Controller | v Mediator.Send(command) | v Pipeline Behaviors | +--> Validation +--> Authorization +--> Logging / Metrics +--> Idempotency +--> Transaction v Command Handler | v Aggregate | v Repository | v Outbox | v Database Commit

## समस्या: छोटा डिलीवरी नोट महंगा क्यों हो जाता है?

आइए कल्पना करें कि हम मार्केटप्लेस एप्लिकेशन में ऑर्डर में एक डिलीवरी नोट जोड़ते हैं। पहली नज़र में यह सिर्फ एक स्ट्रिंग फ़ील्ड है। हालाँकि, उत्पादन में, वही फ़ील्ड भुगतान सारांश, विक्रेता पैनल, शिपिंग एकीकरण, ग्राहक ईमेल और ऑडिट रिकॉर्ड में दिखाई देती है।```text
AddDeliveryNote
  -> sipariş kuralı
  -> validasyon
  -> audit
  -> notification
  -> seller projection
  -> müşteri görünümü
```स्तरित संरचना में, यह परिवर्तन तकनीकी भूमिकाओं में वितरित किया जाता है। वर्टिकल स्लाइस में, प्रश्न बदलता है: यह व्यवहार किस उपयोगकर्ता के इरादे से संबंधित है और इसे किस स्थिरता सीमा पर पूरा किया जाना चाहिए?

## पहले उल्लेख पर अवधारणाएँ```text
Command
Sistemin durumunu değiştirmek isteyen niyettir. Örneğin AddDeliveryNote bir command'dir; başarılı olabilir, reddedilebilir veya hata alabilir.

Query
Sistemin durumunu değiştirmeden veri okuma isteğidir. Örneğin GetOrderSummary bir query'dir.

Handler
Bir command veya query'nin uygulama seviyesindeki akışını yöneten sınıftır. Handler orkestrasyon yapar; iş kuralının kalıcı sahibi olmamalıdır.

Pipeline Behavior
Handler'a ulaşmadan önce veya sonra çalışan ortak teknik adımdır. Validation, authorization, logging, idempotency ve transaction burada konumlanabilir.

Aggregate
Sistemde asla bozulmaması gereken iş kurallarını, yani invariant'ları, koruyan domain nesnesidir. Örneğin iptal edilmiş siparişe teslimat notu eklenememesi aggregate kuralıdır.

Read Model
Domain entity'nin kopyası değildir; bir ekranın veya API cevabının ihtiyaç duyduğu okuma şeklidir.

Projection
Event veya write model değişikliklerinden read model üreten süreçtir. Örneğin DeliveryNoteUpdated event'inden SellerOrderSummary read model'ini günceller.

Outbox
Veritabanı değişikliği ile event yayınını aynı local transaction içinde güvenceye alan kayıt desenidir.

CDC
Change Data Capture, veritabanı loglarından değişiklikleri okuyup dış sistemlere taşıma yaklaşımıdır. Domain event tasarımı yerine DB değişimini kaynak alır.
```ये हिस्से विनिमेय नहीं हैं। हैंडलर एक डोमेन नियम नहीं है; डोमेन व्यवहार का आह्वान करता है. पाइपलाइन कोई व्यावसायिक नीति नहीं है; सामान्य अनुप्रयोग सुरक्षा लाइन है. आउटबॉक्स दलाल नहीं है; यह घटना का लेन-देन संबंधी रिकॉर्ड है जिसे खोना नहीं चाहिए।

## सच्ची कहानी: नोट का टुकड़ा ऑर्डर करें

आइए एक `AddDeliveryNote` उपयोग केस डिज़ाइन करें। उपयोगकर्ता ऑर्डर में एक डिलीवरी नोट जोड़ना चाहता है। सिस्टम पहले उपयोगकर्ता के ऑर्डर बदलने के अधिकार की जांच करता है, नोट की लंबाई की पुष्टि करता है, समग्र पर व्यवहार चलाता है, परिवर्तन को सहेजता है और अन्य स्क्रीन को अपडेट करने के लिए ईवेंट उत्पन्न करता है।```text
Features/Orders/AddDeliveryNote
  AddDeliveryNoteEndpoint.cs
  AddDeliveryNoteCommand.cs
  AddDeliveryNoteValidator.cs
  AddDeliveryNoteHandler.cs
  AddDeliveryNoteResponse.cs
  AddDeliveryNoteTests.cs
```यह निर्देशिका "मिनी लेयर्स" का कब्रिस्तान नहीं होनी चाहिए। प्रत्येक फ़ाइल की एक ही जिम्मेदारी होती है: एंडपॉइंट HTTP अनुबंध को वहन करता है, कमांड इरादे को व्यक्त करता है, सत्यापनकर्ता इनपुट सीमा को बनाए रखता है, हैंडलर प्रवाह का प्रबंधन करता है, समग्र व्यवसाय नियम को लागू करता है, परीक्षण व्यवहार को साबित करता है।

## एल्गोरिथम डिज़ाइन

स्यूडोकोड स्तर पर स्लाइस इस तरह काम करता है:```text
algorithm AddDeliveryNote(command):
  input: orderId, customerId, note, requestId
  output: AddDeliveryNoteResult

  validate command
  reject if requestId was processed before

  order = orderRepository.load(orderId)
  reject if order does not exist
  reject if order.customerId != customerId

  order.addDeliveryNote(note)
  outbox.add(DeliveryNoteUpdated(orderId, note, occurredAt))

  transaction.commit()
  return success(orderId, note)
```सामान्य प्रवाह में समय जटिलता O(1) है; क्योंकि इसे एकल समग्र पहचान के माध्यम से लोड किया जाता है, एक निश्चित संख्या में नियम निष्पादित होते हैं और एक निश्चित संख्या में घटनाएं लिखी जाती हैं। यदि निष्क्रियता नियंत्रण एक अद्वितीय सूचकांक के साथ किया जाता है, तो खोज लागत व्यावहारिक रूप से ओ (लॉग एन) है, जबकि हैश-आधारित कैश या कुंजी-मूल्य स्टोर के साथ, औसत लागत ओ (1) है। मेमोरी जटिलता O(1) है; हैंडलर केवल आवश्यक समग्र स्थिति और कमांड डेटा रखता है, संपूर्ण ऑर्डर इतिहास नहीं।

## यह समस्या क्यों थी?

समस्या आमतौर पर कोड की लंबाई को लेकर नहीं है। समस्या यह है कि एक ही व्यवहार को कई तकनीकी परतों में आधी-अधूरी जानकारी के साथ दर्शाया जाता है।```text
Controller doğrular gibi yapar
Service iş kuralı gibi yapar
Repository veri kuralı gibi yapar
Frontend tekrar kontrol eder
Test mock sırasını korur
```इस मॉडल में, एकल उत्तरदायित्व दिखाई देता है लेकिन व्यवहार स्तर पर नहीं। प्रत्येक वर्ग तकनीकी रूप से छोटा हो सकता है; लेकिन व्यावसायिक निर्णय खंडित है। वर्टिकल स्लाइस SOLID को वर्ग नामों से व्यवहार स्वामित्व की ओर ले जाता है। यहां इंटरफ़ेस पृथक्करण का अर्थ `IOrderService` जैसे फूले हुए अनुबंध के बजाय `IAddDeliveryNoteAuthorization`, `IOrderRepository` और `IRequestDeduplicationStore` जैसे संकीर्ण पोर्ट का उपयोग करना है।

## सीक्यूआरएस और मध्यस्थ पाइपलाइन

कमांड और क्वेरी के बीच अंतर स्लाइस के इरादे को स्पष्ट करता है।```csharp
public sealed record AddDeliveryNoteCommand(
    Guid OrderId,
    Guid CustomerId,
    string Note,
    string RequestId) : ICommand<AddDeliveryNoteResult>;

public sealed class AddDeliveryNoteHandler(
    IOrderRepository orders,
    IRequestDeduplicationStore deduplication,
    IOutboxWriter outbox,
    IUnitOfWork unitOfWork)
    : ICommandHandler<AddDeliveryNoteCommand, AddDeliveryNoteResult>
{
    public async Task<AddDeliveryNoteResult> Handle(
        AddDeliveryNoteCommand command,
        CancellationToken cancellationToken)
    {
        if (await deduplication.ExistsAsync(command.RequestId, cancellationToken))
        {
            return AddDeliveryNoteResult.AlreadyProcessed(command.OrderId);
        }

        var order = await orders.GetByIdAsync(command.OrderId, cancellationToken)
            ?? throw new OrderNotFoundException(command.OrderId);

        order.EnsureOwnedBy(command.CustomerId);
        order.AddDeliveryNote(command.Note);

        await outbox.AddAsync(
            DeliveryNoteUpdated.From(order),
            cancellationToken);

        await unitOfWork.CommitAsync(cancellationToken);
        return AddDeliveryNoteResult.Updated(order.Id, order.DeliveryNote);
    }
}
```मध्यस्थ का उपयोग यहां एक उपकरण है, लक्ष्य नहीं। वास्तविक मूल्य यह है कि पाइपलाइन सत्यापन, प्राधिकरण, लेनदेन, लॉगिंग और हैंडलर से बाहर दोहराए जाने वाले प्रवाह को स्थानांतरित करती है। हालाँकि, पुस्तकालय चयन का मूल्यांकन लाइसेंस, एओटी अनुपालन, प्रतिबिंब लागत और संस्थागत अनुमोदन प्रक्रिया के साथ-साथ तकनीकी प्रदर्शन के साथ किया जाना चाहिए। किसी रूपरेखा निर्णय को स्थायी बनाने से पहले, लाइसेंस पाठ और संगठनात्मक नीति को सत्यापित किया जाना चाहिए।

## क्वेरी पक्ष कैसे प्रवाहित होता है?

कमांड पक्ष व्यवसाय नियम और लेनदेन पर केंद्रित है। क्वेरी पक्ष पढ़ने की दक्षता और उपयोगकर्ता अनुभव पर केंद्रित है। अधिकांश समय हम ऑर्डरों की सूची प्रदर्शित करने के लिए समग्रता लोड नहीं करना चाहते; स्क्रीन के लिए उपयुक्त एक संकीर्ण रीड मॉडल पर्याप्त है।```text
GET /orders
      |
      v
Authorization
      |
      v
Cache
      |
      v
Read Database / Search Index
      |
      v
DTO Mapping
      |
      v
Response
```इस श्रृंखला में कैश केवल एक प्रदर्शन उपकरण नहीं है; यह एक लागत निर्णय भी है. वह डेटा जो बार-बार पढ़ा जाता है, शायद ही कभी बदलता है, और कुछ सेकंड की देरी को सहन करता है, कैशिंग के लिए उपयुक्त है। उस डेटा के लिए जिसके लिए मजबूत स्थिरता की आवश्यकता होती है, जैसे भुगतान स्थिति, कैश नीति को अधिक सावधानी से डिज़ाइन किया जाना चाहिए।

## विकल्प

| वैकल्पिक | ताकत | स्वीकृत मूल्य |
| --- | --- | --- |
| सरल सीआरयूडी सेवा | सबसे कम स्टार्टअप लागत | जैसे-जैसे व्यवहार बढ़ता है, सामान्य सेवा बढ़ती है |
| वर्टिकल स्लाइस, कोई सीक्यूआरएस नहीं | सुविधा स्थानीयता सुनिश्चित करती है | पढ़ने/लिखने का इरादा कम दिखाई दे सकता है |
| वर्टिकल स्लाइस + सीक्यूआरएस | आशय, परीक्षण और पाइपलाइन के बीच अंतर स्पष्ट हो जाता है | अधिक कक्षा और अनुबंध अनुशासन की आवश्यकता |
| भौतिक रूप से अलग किया गया पढ़ने/लिखने का मॉडल | पढ़ने का प्रदर्शन और पैमाने की स्वतंत्रता | अंतिम स्थिरता, आउटबॉक्स, प्रक्षेपण और संचालन लागत जोड़ता है |
| माइक्रोसर्विस | स्वतंत्र तैनाती और पैमाना | नेटवर्क, डेटा स्थिरता, अवलोकनशीलता और टीम की लागत में वृद्धि |

एक छोटी सीआरयूडी सतह पर, सबसे अच्छा निर्णय अक्सर वर्टिकल स्लाइस + सरल हैंडलर होता है। भौतिक सीक्यूआरएस या माइक्रोसर्विस को केवल तभी चुना जाना चाहिए जब पढ़ने/लिखने का ओवरहेड, टीम स्वामित्व और गलती अलगाव लागत को उचित ठहराता हो।

## निर्णय: पहले तार्किक सीमा, फिर शारीरिक अलगाव

मेरा डिफ़ॉल्ट निर्णय है: पहले तार्किक रूप से एप्लिकेशन के भीतर स्लाइस को अलग करें; फिर, यदि माप भौतिक अलगाव को मजबूर करता है, तो एक रीड मॉडल, ब्रोकर, कैश या अलग सेवा जोड़ें।```text
Aşama 1: Modular monolith içinde slice
Aşama 2: Command/query ayrımı
Aşama 3: Outbox ve projection
Aşama 4: Ayrı read store veya cache
Aşama 5: Gerekirse ayrı deploy birimi
```यह क्रम लागत को स्थगित करता है लेकिन डिज़ाइन को नहीं। यदि कोड सीमा सही ढंग से खींची गई है, तो भौतिक पृथक्करण पुनर्लेखन नहीं बल्कि नियंत्रित घटाव है।

## डेटा पृथक्करण: तार्किक भौतिक के समान नहीं है

पढ़ें प्रतिकृति CQRS नहीं है. रेप्लिका एक ही स्कीमा को एक अलग नोड से पढ़ती है; दूसरी ओर, CQRS, उपयोग पैटर्न के अनुसार रीडिंग मॉडल को नया आकार देता है।```text
Replica
  → aynı tablo
  → aynı join ihtiyacı
  → daha fazla okuma kapasitesi

Projection
  → ekran için hazırlanmış veri
  → daha az join
  → daha düşük latency ve I/O
```उदाहरण के लिए, ऑर्डर सूची में हर बार `CityId` को जोड़ने के बजाय, प्रक्षेपण में `CityName` लिखना एक असामान्यीकरण निर्णय है। यह निर्णय लेखन पक्ष पर अतिरिक्त सिंक्रनाइज़ेशन लागत पैदा करता है; रीडिंग साइड पर, यह सिंगल रीडिंग के साथ स्क्रीन को फीड कर सकता है।

## दोहरी लेखन, आउटबॉक्स और सीडीसी

सबसे खतरनाक प्रवाह है:```text
1. Siparişi veritabanına yaz
2. Broker'a event gönder
3. İkinci adımda sistem çöksün
```इस मामले में आदेश तो है लेकिन आयोजन नहीं. शिपिंग, अधिसूचना या प्रक्षेपण पीछे रह गए हैं। ट्रांजेक्शनल आउटबॉक्स इस अंतर को पाटता है: व्यावसायिक डेटा और प्रकाशित होने वाली घटना एक ही स्थानीय लेनदेन में लिखी जाती है। एक प्रकाशक या सीडीसी-आधारित प्रक्रिया फिर आउटबॉक्स रिकॉर्ड को ब्रोकर के पास ले जाती है।

| कसौटी | आउटबॉक्स | सीडीसी |
| --- | --- | --- |
| डोमेन इवेंट नियंत्रण | आवेदन निर्धारित करता है | डीबी परिवर्तन निर्धारित करता है |
| घटना का आशय | खुला | अप्रत्यक्ष |
| डीबी स्कीमा निर्भरता | निचला | उच्च |
| घटना सामग्री | व्यवसायिक भाषा के साथ डिज़ाइन किया गया | तालिका/लॉग संरचना से प्रभावित |
| माइक्रोसर्विस अनुपालन | बहुत ऊँचा | निर्भर करता है |
| स्थापना लागत | अधिक एप्लिकेशन कोड | अधिक बुनियादी ढांचे की जानकारी |

सीडीसी एक शक्तिशाली उपकरण है; यह मौजूदा प्रणालियों में परिवर्तन लाने में विशेष रूप से मूल्यवान है। हालाँकि, यदि एप्लिकेशन यह निर्धारित करता है कि डोमेन ईवेंट का क्या अर्थ है, तो आउटबॉक्स एक स्पष्ट अनुबंध तैयार करता है।

कम से कम एक बार डिलीवरी से दोबारा डिलीवरी हो सकती है। इसलिए उपभोक्ता को नपुंसक होना चाहिए।```text
DeliveryNoteUpdated event'i iki kez geldi
  → projection aynı version'ı gördü
  → ikinci işlem no-op oldu
```निरंकुशता यहाँ कोई आभूषण नहीं है; यह वितरित प्रणाली में डेटा स्थिरता का व्यावहारिक बीमा है।

## क्लाउड लागत: स्लाइस इनवॉइस को क्यों प्रभावित करती है?

वर्टिकल स्लाइस सिर्फ कोड संगठन नहीं है; यह पैमाने की इकाई को भी दृश्यमान बनाता है। यदि चेकआउट लेखन पक्ष सीपीयू गहन है और कैटलॉग रीड पक्ष मेमोरी और कैश गहन है, तो दोनों को एक ही संसाधन प्रोफ़ाइल पर मजबूर करने से अपशिष्ट उत्पन्न होता है।```text
Checkout command side
  → düşük concurrency
  → yüksek tutarlılık
  → transaction ve fraud kontrolü

Catalog query side
  → yüksek concurrency
  → cache ve projection
  → düşük latency beklentisi
```असममित भार के लिए असममित संसाधनों की आवश्यकता होती है। हालाँकि, प्रत्येक कैश, NAT, लोड बैलेंसर, कतार, रीड स्टोर और अलग तैनाती इकाई इनवॉइस में एक नया आइटम जोड़ती है। इसलिए, वास्तुशिल्प निर्णय वास्तविक मेट्रिक्स के साथ किया जाना चाहिए: पी95 विलंबता, पढ़ने/लिखने का अनुपात, कनेक्शन संतृप्ति, निकास, पुनः प्रयास मात्रा और घटना विस्फोट त्रिज्या।

## प्रदर्शन और स्मृति विश्लेषण

किसी स्लाइस के गर्म पथ से अनावश्यक आवंटन नहीं होना चाहिए। अनुरोध मॉडल को सीधे डोमेन इकाई में अनुवादित करने के बजाय, हैंडलर केवल उन फ़ील्ड्स को स्थानांतरित करता है जिनकी उसे आवश्यकता होती है। क्वेरी पक्ष पर समग्र लोड करने के बजाय प्रक्षेपण पढ़ने से सीपीयू, मेमोरी और I/O लागत कम हो जाती है।```text
Command path
  → tek aggregate
  → kısa transaction
  → sabit event sayısı

Query path
  → ihtiyaca göre projection
  → minimum column set
  → pagination veya cursor
```यदि पृष्ठ का आकार `p` है तो लिस्टिंग क्वेरी की जटिलता O(p) है। कर्सर पेजिनेशन के साथ, मेमोरी O(p) बनी रहती है; संपूर्ण सूची को संग्रहीत करने से O(n) मेमोरी की खपत होती है और उत्पादन में अनावश्यक जोखिम पैदा होता है।

## परीक्षण रणनीति

वर्टिकल स्लाइस परीक्षणों को व्यवहारिक आत्मविश्वास को अनुकूलित करना चाहिए, न कि मॉक की संख्या को।

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

परीक्षण पिरामिड का उद्देश्य प्रत्येक वर्ग को अलग करना नहीं है; उस बिंदु का तुरंत पता लगाना है जहां निर्णय पलट दिया गया है।

## व्यापार बंद

वर्टिकल स्लाइस अधिक छोटी फ़ाइलें उत्पन्न करता है। यह एक सचेत कीमत है. बदले में, परिवर्तन का कारण, परीक्षण कवरेज और रोलबैक सतह अधिक दिखाई देने लगती है।

गलत तरीके से लागू करने पर दो जोखिम उत्पन्न होते हैं। पहला यह है कि प्रत्येक स्लाइस अपना स्वयं का मिनी-फ्रेमवर्क तैयार करता है। दूसरा यह है कि `Shared` फ़ोल्डर असीमित रूप से बढ़ता है और पुराने स्तरित मोनोलिथ का नया नाम बन जाता है। समाधान संकीर्ण इंटरफेस, खुले पोर्ट, वास्तुशिल्प परीक्षण और एडीआर के साथ निर्णय रिकॉर्डिंग है।

## बार-बार भ्रमित होना```text
❌ Vertical Slice = controller'dan repository'ye kadar her şeyi aynı klasöre koymak
✓ Kullanıcı niyetinin davranış, veri ve test sınırını birlikte tasarlamaktır.

❌ CQRS = mutlaka ayrı veritabanı
✓ CQRS önce niyet ayrımıdır; fiziksel ayrım ayrı bir maliyet kararıdır.

❌ Mediator = mimari
✓ Mediator yalnızca dispatch ve pipeline aracıdır; mimari sınırı feature sahipliği belirler.

❌ Outbox = exactly-once garantisi
✓ Outbox event kaybını önler; consumer yine idempotent olmalıdır.

❌ Read replica = projection
✓ Replica aynı modeli çoğaltır; projection okuma ihtiyacına göre yeni model üretir.

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

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

यदि इन प्रश्नों का उत्तर स्पष्ट नहीं है, तो अधिक बुनियादी ढांचे को जोड़ने के बजाय स्लाइस सीमा को सरल बनाना अक्सर सस्ता होता है।

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

1. वर्टिकल स्लाइस अनुरोध से परीक्षण तक एकल उपयोगकर्ता के इरादे की व्यवहार सीमा है।
2. सीक्यूआरएस, मध्यस्थ, आउटबॉक्स और प्रोजेक्शन एक ही निर्णय नहीं हैं; प्रत्येक अलग-अलग लागत और सुरक्षा समस्याओं का समाधान करता है।
3. तार्किक सुविधा सीमा को पहले सत्यापित करने से भौतिक पृथक्करण की लागत नियंत्रित रहती है।
4. वितरित प्रणाली में आउटबॉक्स घटना हानि को कम करता है; निष्क्रियता पुनर्वितरण को क्षति पहुंचाने से रोकती है।
5. क्लाउड लागत आर्किटेक्चर से बाहर नहीं है; प्रत्येक सीमा एक गणना, I/O, नेटवर्क और ऑपरेशन आइटम बन जाती है।

अंत-से-अंत प्रवाह```text

POST /orders | v Endpoint / Controller | v Mediator.Send() | v Validation | v Authorization | v Transaction | v Command Handler | v Aggregate | v Repository | v Outbox | v Commit | v Broker / Kafka | v Projection | v Read Database | v GET /orders | v Query Handler | v Frontend

अगले भाग में, हम जांच करेंगे कि उत्पादन में वर्टिकल स्लाइस, डीडीडी एग्रीगेट और मॉड्यूलर मोनोलिथ सीमाओं को एक साथ कैसे बनाए रखा जाए।