माइक्रोसर्विसेज में डोमेन-संचालित डिज़ाइन (डीडीडी)।

जब संगठन एक अखंड वास्तुकला से माइक्रोसर्विसेज में परिवर्तित होते हैं, तो उन्हें एक महत्वपूर्ण, उच्च जोखिम वाले प्रश्न का सामना करना पड़ता है: हम अपनी सेवाओं की सीमाएँ कैसे बनाते हैं?

सिद्धांत रूप में, माइक्रोसर्विसेज ढीली, वियुग्मित इकाइयाँ होनी चाहिए जिन्हें स्वतंत्र रूप से विकसित, तैनात और स्केल किया जा सकता है। हालाँकि, व्यवहार में, कई टीमें एक वितरित मोनोलिथ का निर्माण करती हैं - एक ऐसी प्रणाली जहाँ सेवाएँ इतनी मजबूती से जुड़ी होती हैं कि एक ही व्यवसाय परिवर्तन के लिए एक साथ कई सेवाओं को संशोधित और तैनात करने की आवश्यकता होती है, जिससे नेटवर्क विलंबता और तैनाती ग्रिडलॉक की स्थिति बनती है।

इस नुकसान से बचने के लिए, सॉफ़्टवेयर आर्किटेक्ट डोमेन-संचालित डिज़ाइन (डीडीडी) की ओर रुख करते हैं। पहली बार 2003 में एरिक इवांस द्वारा पेश किया गया, डीडीडी एक सॉफ्टवेयर विकास पद्धति है जो कोड संरचनाओं को उन जटिल व्यावसायिक डोमेन के साथ संरेखित करती है जिनका वे प्रतिनिधित्व करते हैं।

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

1. रणनीतिक खाका: सेवा सीमाएँ खींचना

DDD को दो प्राथमिक चरणों में विभाजित किया गया है: रणनीतिक डिज़ाइन और सामरिक डिज़ाइन। रणनीतिक डिज़ाइन व्यावसायिक संदर्भों को मॉडलिंग करने और सेवा सीमाओं को परिभाषित करने के बारे में है। यह वास्तुकला का “मैक्रो” दृश्य प्रदान करता है।

ए. सर्वव्यापी भाषा

एक व्यवसाय के भीतर, अलग-अलग विभाग पूरी तरह से अलग-अलग चीजों के लिए समान शब्दों का उपयोग करते हैं। उदाहरण के लिए:

• सेल्स टीम के लिए, एक “उपयोगकर्ता” एक लीड या संभावित ग्राहक होता है।
• सुरक्षा टीम के लिए, एक “उपयोगकर्ता” लॉगिन क्रेडेंशियल का एक सेट है।
• शिपिंग टीम के लिए, “उपयोगकर्ता” एक भौतिक प्राप्तकर्ता पता है।

एक “उपयोगकर्ता” के लिए एक एकल, एकीकृत डेटाबेस मॉडल बनाने की कोशिश करना जो सभी को संतुष्ट करता है, परिणाम एक विशाल, पेचीदा कोडबेस है। डीडीडी एक सर्वव्यापी भाषा स्थापित करके इसका समाधान करता है - एक साझा शब्दावली जो एक विशिष्ट सीमा के भीतर व्यावसायिक डोमेन विशेषज्ञों और डेवलपर्स दोनों द्वारा परिभाषित और उपयोग की जाती है।

बी. बंधे हुए संदर्भ

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

एकल “उपयोगकर्ता” मॉडल के बजाय, हम अलग-अलग मॉडलों को उनके संबंधित सीमित संदर्भों में परिभाषित करते हैं: *ऑर्डर संदर्भ में, हमारे पास एक Order मॉडल है जिसमें ग्राहक संपर्क जानकारी शामिल है।

• पहचान संदर्भ में, हमारे पास एक Credentials मॉडल है।
• शिपिंग संदर्भ में, हमारे पास एक DeliveryAddress मॉडल है।

माइक्रोसर्विसेज का सुनहरा नियम: एक बाउंडेड कॉन्टेक्स्ट सीधे एक माइक्रोसर्विसेज पर मैप करता है।

सिस्टम को बंधे हुए संदर्भों में विभाजित करके, हम यह सुनिश्चित करते हैं कि माइक्रोसर्विसेज शिथिल रूप से युग्मित हैं और विशिष्ट व्यावसायिक क्षमताओं का प्रतिनिधित्व करते हैं।

सी. संदर्भ मानचित्रण: सेवाएँ कैसे संचार करती हैं

बंधे हुए संदर्भ अलगाव में मौजूद नहीं होते हैं; उन्हें बातचीत करनी चाहिए. एक संदर्भ मानचित्र संदर्भों के बीच संबंधों और अनुवाद तंत्र को परिभाषित करता है। मुख्य पैटर्न में शामिल हैं:

• साझा कर्नेल: दो संदर्भ डोमेन मॉडल और डेटाबेस का एक छोटा उपसमूह साझा करते हैं (आमतौर पर युग्मन के कारण माइक्रोसर्विसेज में हतोत्साहित किया जाता है)।
• ग्राहक-आपूर्तिकर्ता: एक संदर्भ (आपूर्तिकर्ता) को दूसरे (ग्राहक) को डेटा प्रदान करना होगा। आपूर्तिकर्ता को ग्राहक के साथ रिलीज़ शेड्यूल का समन्वय करना होगा।
• भ्रष्टाचार-रोधी परत (एसीएल): एक अनुवाद परत जो बाहरी सिस्टम से आने वाले डेटा को क्लाइंट के आंतरिक डोमेन मॉडल में अनुवादित करती है, बाहरी मॉडल को आंतरिक वास्तुकला को प्रदूषित करने से रोकती है।

2. सामरिक खाका: माइक्रोसर्विस कोडबेस की संरचना करना

एक बार जब रणनीतिक डिज़ाइन का उपयोग करके सेवा की सीमाएँ खींची जाती हैं, तो टैक्टिकल डिज़ाइन एक एकल माइक्रोसर्विसेज के भीतर कोड को संरचित करने के लिए डिज़ाइन पैटर्न का एक सेट प्रदान करता है।

ए. संस्थाएं और मूल्य वस्तुएं

माइक्रोसर्विस के अंदर, मॉडलों को दो श्रेणियों में विभाजित किया जाता है:

1. इकाइयाँ: ऐसी वस्तुएँ जिनकी एक विशिष्ट पहचान होती है जो समय के साथ बनी रहती है, भले ही उनकी विशेषताएँ बदल जाएँ। उदाहरणों में Order या Product शामिल हैं।
2. मूल्य वस्तुएं: ऐसी वस्तुएं जिनकी कोई विशिष्ट पहचान नहीं होती है और वे पूरी तरह से उनकी विशेषताओं से परिभाषित होती हैं। वे अपरिवर्तनीय हैं. उदाहरणों में ShippingAddress या ProductDimensions शामिल हैं। यदि दो मूल्य वाली वस्तुओं में समान गुण हैं, तो उन्हें समान माना जाता है।

बी. समुच्चय और समुच्चय जड़ें

एक एग्रीगेट संबद्ध संस्थाओं और मूल्य वस्तुओं का एक समूह है जिसे डेटा परिवर्तनों के लिए एकल इकाई के रूप में माना जाता है। प्रत्येक समुच्चय में एक एग्रीगेट रूट होता है, जो एकमात्र प्रवेश बिंदु है जिसके माध्यम से बाहरी वस्तुएं समुच्चय के साथ बातचीत कर सकती हैं। रूट यह सुनिश्चित करता है कि सभी व्यावसायिक परिवर्तन (नियम) लागू हों।

उदाहरण के लिए, उपरोक्त चित्र में:

• ऑर्डर सर्विस में, Order एग्रीगेट रूट है। इसमें OrderItem (इकाई) और ShippingAddress (वैल्यू ऑब्जेक्ट) शामिल हैं। बाहरी सेवाएँ सीधे OrderItem को संशोधित नहीं कर सकतीं; उन्हें Order रूट (उदाहरण के लिए, order.AddItem()) पर एक विधि को कॉल करना होगा, जो पुष्टि करता है कि ऑर्डर पहले से ही शिप नहीं किया गया है।

सी. डोमेन इवेंट

डोमेन इवेंट उस डोमेन में हुआ कुछ ऐसा है जिसकी व्यावसायिक विशेषज्ञ परवाह करते हैं। इसका उपयोग बंधे हुए संदर्भों में परिवर्तनों को अतुल्यकालिक रूप से संप्रेषित करने के लिए किया जाता है। जब कोई एग्रीगेट एक कमांड निष्पादित करता है, तो यह एक डोमेन इवेंट प्रकाशित करता है (उदाहरण के लिए, OrderCreated)। अन्य सेवाएँ इस घटना को सुनती हैं और तदनुसार अपनी स्थिति को अपडेट करती हैं, जिससे सिंक्रोनस एपीआई निर्भरता के बिना अंतिम स्थिरता सुनिश्चित होती है।

3. एक ठोस उदाहरण: ऑर्डर सेवा बनाम इन्वेंटरी सेवा

आइए ऑर्डर सर्विस के लिए गो में सामरिक डीडीडी के सरलीकृत कार्यान्वयन को देखें, जिसमें दिखाया गया है कि एग्रीगेट रूट कैसे व्यावसायिक नियमों का समन्वय करता है।

package domain

import (
	"errors"
	"time"
)

// Value Object (Immutable, identity-less)
type ShippingAddress struct {
	Street  string
	City    string
	ZipCode string
}

// Entity (Has identity, mutable)
type OrderItem struct {
	ProductID string
	Quantity  int
	Price     float64
}

// Aggregate Root (Enforces transactional boundaries)
type Order struct {
	ID        string
	Items     []OrderItem
	Address   ShippingAddress
	Status    string
	CreatedAt time.Time
}

// NewOrder creates a new Order Aggregate Root
func NewOrder(id string, address ShippingAddress) *Order {
	return &Order{
		ID:        id,
		Items:     []OrderItem{},
		Address:   address,
		Status:    "PENDING",
		CreatedAt: time.Now(),
	}
}

// AddItem enforces business rules before mutating state
func (o *Order) AddItem(productID string, qty int, price float64) error {
	if o.Status != "PENDING" {
		return errors.New("cannot add items to a finalized or cancelled order")
	}
	if qty <= 0 {
		return errors.New("quantity must be greater than zero")
	}
	
	o.Items = append(o.Items, OrderItem{
		ProductID: productID,
		Quantity:  qty,
		Price:     price,
	})
	return nil
}

जब ऑर्डर सफलतापूर्वक सहेजा जाता है, तो सेवा एक संदेश ब्रोकर को एक ईवेंट प्रकाशित करती है:

{
  "event_id": "evt_98231",
  "event_type": "OrderCreated",
  "timestamp": "2026-06-26T00:15:00Z",
  "payload": {
    "order_id": "ord_5521",
    "items": [
      { "product_id": "prod_88", "quantity": 2 }
    ]
  }
}

इन्वेंटरी सेवा इस घटना को सुनती है, अपनी स्थानीय StockLevel इकाई को अपडेट करती है, और प्रवाह को अतुल्यकालिक रूप से पूरा करती है।

4. माइक्रोसर्विसेज में रणनीतिक बनाम सामरिक डीडीडी

निष्कर्ष: सबसे पहले रणनीतिक डीडीडी से शुरुआत करें

डोमेन-संचालित डिज़ाइन को माइक्रोसर्विसेज़ पर लागू करना यह सुनिश्चित करने का एक शक्तिशाली तरीका है कि आपका आर्किटेक्चर आपकी व्यावसायिक संरचना से मेल खाता है। हालाँकि, टीमें अक्सर रणनीतिक डिजाइन को नजरअंदाज करते हुए सामरिक पैटर्न (जैसे रिपॉजिटरी इंटरफेस और वैल्यू ऑब्जेक्ट लिखना) पर बहुत अधिक ध्यान केंद्रित करने की गलती करती हैं।

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

ग़ज़निक्स ब्लॉग पर अधिक सॉफ़्टवेयर आर्किटेक्चर, डिज़ाइन पैटर्न और इंजीनियरिंग अंतर्दृष्टि का अन्वेषण करें →