क्या एडीआई इंफ्रास्ट्रक्चर क्लास डीडीडी में डोमेन का हिस्सा होना चाहिए?

Question

मैं एक आरईएसटी एपीआई का खुलासा करने वाले बैकएंड एप्लिकेशन पर काम करता हूं और मैं (मेरी कोशिश करता हूं) मेरी परियोजना में डोमेन संचालित डिजाइन का उपयोग करता हूं।

आरईएसटी एपीआई डोमेन कक्षाओं के एक निश्चित सेट पर काम करता है। डोमेन से प्रत्येक एजगेट रूट के लिए एक अलग आरईएसटी एंडपॉइंट है। हालांकि, सभी प्रयासों के बावजूद, ऐसे मामले हैं जब नए वर्ग, डोमेन वर्गों (बुनियादी ढांचे वर्ग) से पाने नहीं उभरने, जैसे हैं:

• बैच कार्रवाई कॉलम के साथ [{"id": 1, "status": "success"},{"id": 2, "status": "failure", "message": "detailed message"}]
• एक वर्ग के एक वर्ग होल्डिंग स्थितियां उपयोगकर्ता द्वारा चुना [{"column": "id", "order": 1}, {"column":"created", "order": 2 }]

अब दो विकल्प:

• है यह ठीक REST API क्लासेस का हिस्सा नहीं हैं दर्शाना डोमेन?
• या इन कक्षाओं को डोमेन का हिस्सा बनना चाहिए?

Answer 1

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

यह वही है जो आवेदन सेवाएं हैं।

बिल्ड एक पतली आपके डोमेन मॉडल के आसपास परत है कि आवेदन सेवाओं में शामिल है (अक्सर सेवा लेयर कहा जाता है)। ऐप सेवाएं डोमेन मॉडल के प्रत्यक्ष ग्राहक हैं। वे आम तौर पर के आसपास व्यवस्थित होते हैं, उदाहरण के बजाय मामले का उपयोग करें। अब आपका आरईएसटी एपीआई डोमेन मॉडल की बजाय ऐप सेवाओं का प्रत्यक्ष ग्राहक है।

आपके द्वारा उल्लेख किए जाने वाले दो वर्गों में भी अच्छी तरह से सेवा परत में फिट होगा।

संपादित करें:

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