अच्छी सेवा सीमाएँ व्यावसायिक क्षमताओं का पालन करती हैं, तकनीकी परतों को नहीं। Domain-Driven Design (DDD) इसके लिए एक सटीक उपकरण देता है: बाउंडेड संदर्भ — एक सीमा जिसके भीतर एक डोमेन मॉडल और इसकी शर्तें सुसंगत होती हैं।
शब्द "Customer" विभिन्न संदर्भों में विभिन्न चीजों का मतलब हो सकता है। प्रत्येक बाउंडेड संदर्भ अपना स्वयं का मॉडल रखता है, और एक माइक्रोसर्विस आमतौर पर एक संदर्भ से मेल खाता है।
┌───────────────────┐ ┌────────────────────┐
│ Sales context │ │ Support context │
│ Customer = │ │ Customer = │
│ leads, orders │ │ tickets, SLAs │
└───────────────────┘ └────────────────────┘
one service another service
✗ Entity services ("User service", "Product service") — too fine, chatty
✗ Splitting by technical layer (a "database service")
✗ Boundaries that force a distributed transaction for every operation
यदि दो सेवाएँ एक ऑपरेशन पूरा करने के लिए लगातार एक दूसरे को कॉल करती हैं, तो सीमा संभवतः गलत है।
जल्दी तय की गई सीमाएँ बाद में स्थानांतरित करने के लिए बहुत महंगी होती हैं, क्योंकि वे APIs और डेटाबेस में कठोर हो जाती हैं जिन पर अन्य टीमें निर्भर करते हैं।
DDD बाउंडेड संदर्भ आपको व्यावसायिक के साथ इन पंक्तियों को खींचने का एक सिद्धांतबद्ध तरीका देते हैं, ताकि सेवाएँ सुसंगत रहें और लगातार समन्वय करने के बजाय स्वतंत्र रूप से विकसित हो सकें।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें