डीडीडी कोड: इकाई, मूल्य वस्तु और समुच्चय (Ddd Entity Value Object Aggregate)

इस लेख का प्रश्न

पहले भाग में, हमने व्यवसाय की भाषा और नियमों से शुरुआत की। अब सवाल यह है कि हम इन निर्णयों को कोड में कहां रखते हैं? हम एक ही ई-कॉमर्स डोमेन का उपयोग करेंगे: पैसा, ऑर्डर लाइन, ऑर्डर और भुगतान प्रवाह।```text Money + Address + Quantity → Value Object OrderLine + Order → Entity Order (Root) + OrderLine → Aggregate Repository → Aggregate Root'u yükler ve kaydeder

## पहले उल्लेख पर अवधारणाएँ```text
📦 Value Object
Kimliği olmayan, değeriyle tanımlanan ve değişmez tutulması gereken kavram.

📦 Entity
Nitelikleri değişse de kimliği boyunca aynı kalan nesne.

📦 Aggregate
Birlikte tutarlı kalması gereken nesnelerin transaction sınırı.

📦 Aggregate Root
Aggregate'e dışarıdan girilebilen tek kapı.
```उदाहरण के लिए, दो `Money(100, "TRY")` समान मान दर्शाते हैं; दो ऑर्डरों की अलग-अलग पहचान होती है, भले ही उनका योग समान हो।

## वैल्यू ऑब्जेक्ट से शुरुआत करें

वैल्यू ऑब्जेक्ट डीडीडी में सोचने का तरीका सबसे अच्छी तरह सिखाता है। `decimal` स्वयं पैसा नहीं है: इसमें मुद्रा, पूर्णांकन, छूट और कर नियम शामिल हैं। इन नियमों को सेवा स्तर पर वितरित करने के बजाय अवधारणा के भीतर संग्रहीत करें।```csharp
public sealed record Money(decimal Amount, string Currency)
{
    public Money Add(Money other)
    {
        if (Currency != other.Currency) throw new DomainException("Currency mismatch");
        return new Money(Amount + other.Amount, Currency);
    }
}
```वैल्यू ऑब्जेक्ट अपरिवर्तनीय है: जब मूल्य बदलता है, तो एक नया उदाहरण बनाया जाता है। इस प्रकार, एक ही पता, ई-मेल, तिथि सीमा या मुद्रा मूल्य विभिन्न लेनदेन चरणों में अप्रत्याशित दुष्प्रभाव उत्पन्न नहीं करता है। तुलना संदर्भ के आधार पर की जाती है; इसलिए, फ़ील्ड की संख्या के साथ समानता लागत O(m) है, लेकिन व्यवसाय नियम एक ही स्थान पर रहने के कारण परिवर्तन लागत कम हो जाती है।

## इकाई: पहचान और जीवनचक्र

`Order` एक इकाई है. अपना पता या कुल बदल सकते हैं; अभी भी वही क्रम है. अंतर सेटर्स का उपयोग करने में नहीं है, बल्कि कार्य व्यवहार के रूप में परिवर्तन को मॉडलिंग करने में है।```text
❌ order.Status = Paid
✓ order.ConfirmPayment(payment)

❌ order.Total = total - discount
✓ order.ApplyDiscount(discount)
````ConfirmPayment` भुगतान के प्रमाण के लिए एक ही स्थान पर जांच करता है कि ऑर्डर रद्द नहीं किया गया है और संक्रमण कानूनी है। इकाई का कार्य प्रत्येक डेटा को स्थानांतरित करना नहीं है, बल्कि उसके जीवन चक्र में अमान्य स्थितियों को रोकना है।

## समुच्चय: वस्तुओं का समूह नहीं, बल्कि एक संगति सीमा

ऑर्डर और उसकी लाइनें एक ही लेन-देन के भीतर सुसंगत रहनी चाहिए: लाइनों की संख्या सकारात्मक है, कुल लाइनों के योग के बराबर है, और ऑर्डर की पुष्टि होने के बाद लाइन को बदला नहीं जा सकता है। तो `Order` `OrderLine` के लिए समग्र रूट बन जाता है।```text
Order aggregate
  ├─ OrderLine
  ├─ ShippingAddress
  └─ Total

Dış dünya → Order.AddLine() / Order.ConfirmPayment()
Dış dünya ↛ OrderLine'a doğrudan yazmaz
```एग्रीगेट को बड़ा बनाने से ताले और संस्करण टकराव पैदा होते हैं, सुरक्षा नहीं। लेखन अनुरोध में यथासंभव एकल समुच्चय को अद्यतन करें। ऑब्जेक्ट संदर्भ के बजाय आईडी द्वारा किसी अन्य एग्रीगेट से कनेक्ट करें; यदि समन्वय की आवश्यकता है, तो डोमेन इवेंट या एप्लिकेशन ऑर्केस्ट्रेशन का उपयोग करें। यह आशावादी समवर्ती संघर्षों और अनावश्यक स्थापना लागत को सीमित करता है।

## डोमेन सेवा और एप्लिकेशन सेवा

यदि कोई नियम स्वाभाविक रूप से एकल समुच्चय से संबंधित नहीं है, तो यह एक डोमेन सेवा हो सकता है: उदाहरण के लिए, विनिमय दर के आधार पर मूल्य निर्धारण। इसके विपरीत, एप्लिकेशन सेवा उपयोग के मामले का प्रबंधन करती है: ऑर्डर लोड करती है, व्यवहार को कॉल करती है, इसे सहेजती है और लेनदेन पूरा करती है।

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

एप्लिकेशन सेवा में नियम डालना एनेमिक मॉडल की सेवा परत पर वापसी है।

## रिपॉजिटरी: टेबल एपीआई नहीं

रिपॉजिटरी डोमेन को इन-मेमोरी संग्रह का अनुभव देता है; यह कोई SQL या ORM विवरण नहीं है. प्रत्येक तालिका के लिए एक रिपॉजिटरी बनाने के बजाय, इसका उपयोग केवल एग्रीगेट रूट्स के लिए करें। चाइल्ड इकाई को सीधे `OrderLineRepository.Find()` से बदलने से रूट द्वारा बनाए गए नियमों को दरकिनार कर दिया जाता है।```text
order = orderRepository.get(orderId)
order.confirmPayment(payment)
orderRepository.save(order)
```यह सीमा परीक्षण में मॉक रिपॉजिटरी के साथ डोमेन व्यवहार के बुनियादी ढांचे-स्वतंत्र सत्यापन को भी सक्षम बनाती है। ORM के खाली कंस्ट्रक्टर या उत्सुक-लोडिंग आवश्यकता को डोमेन मॉडल को आकार नहीं देना चाहिए; मैपिंग एडॉप्टर की ज़िम्मेदारी है.

## मिलान जो झूठा आत्मविश्वास पैदा करता है```text
❌ Value Object = küçük DTO
✓ Value Object değer, doğrulama ve davranış taşır.

❌ Aggregate = mümkün olduğunca büyük nesne grafiği
✓ Aggregate = küçük tutulmuş transaction ve consistency boundary.

❌ Domain Service = iş kuralı çöplüğü
✓ Yalnızca tek Aggregate'e ait olmayan saf domain davranışı.

❌ Repository = her tablo için CRUD API
✓ Repository = Aggregate Root'un kalıcılık sınırı.

आवेदन चेकलिस्ट

1. क्या Money, Email, Address, Quantity जैसी अवधारणाएँ आदिम के रूप में प्रसारित हो रही हैं?
2. क्या प्रत्येक इकाई व्यवहार वास्तव में एक अमान्य स्थिति को रोकता है?
3. क्या एक लिखित अनुरोध एकाधिक समुच्चय को परमाणु रूप से अद्यतन करने का प्रयास करता है?
4. क्या एप्लिकेशन सेवा निर्णय लेती है या केवल योजना बनाती है?
5. क्या रिपॉजिटरी केवल एग्रीगेट रूट्स स्थापित करती है?

सबसे पहले सबसे महंगे व्यवसाय नियम से शुरुआत करें; पूरे सिस्टम को एक बार में सामरिक DDD में न बदलें।

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

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

सामरिक DDD का लक्ष्य अधिक कक्षाएं जोड़ना नहीं है, बल्कि व्यावसायिक नियम को गलत परत में लीक होने से रोकना है।

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