Kotlin में Domain-Driven Design: व्यावसायिक तर्क की जटिलता में कैसे न डूबें

DDD और Kotlin एक आदर्श जोड़ी क्यों हैं

जब कोई प्रोजेक्ट बढ़ता है और व्यावसायिक आवश्यकताएँ एक उलझी हुई गाँठ की तरह दिखने लगती हैं, तो सामान्य CRUD दृष्टिकोण काम करना बंद कर देता है। आप खुद को यह सोचते हुए पाते हैं कि आधा कोड अनंत if-else जाँचों से भरा है, और तर्क में कोई भी बदलाव दर्जनों फ़ाइलों में संशोधन की ओर ले जाता है। परिचित लगता है?

यहाँ पर Domain-Driven Design (DDD) मंच पर आता है — एक दृष्टिकोण जो व्यावसायिक तर्क को ब्रह्मांड के केंद्र में रखता है। और Kotlin, अपने संक्षिप्त सिंटैक्स, शक्तिशाली टाइप सिस्टम और कार्यात्मक अवधारणाओं के समर्थन के साथ, DDD को लागू करने के लिए एक आदर्श उपकरण बन जाता है। इस लेख में, हम यह समझेंगे कि इन दो शक्तियों को कैसे जोड़ा जाए ताकि आपका कोड न केवल काम करे बल्कि अभिव्यंजक और लचीला भी हो।

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

Domain-Driven Design: व्यस्त लोगों के लिए एक संक्षिप्त परिचय

कोड में गोता लगाने से पहले, आइए शब्दों पर सहमत हों। DDD कोई फ्रेमवर्क या लाइब्रेरी नहीं है। यह सिद्धांतों का एक सेट है जो डेवलपर्स और व्यवसाय को एक ही भाषा में बात करने में मदद करता है।

मुख्य अवधारणाएँ:

\n
• Ubiquitous Language (सर्वव्यापी भाषा) — कोड के शब्द व्यावसायिक विश्लेषकों और ग्राहकों द्वारा उपयोग किए जाने वाले शब्दों से मेल खाने चाहिए।
\n
• Bounded Context (सीमित संदर्भ) — एक स्पष्ट सीमा जिसके भीतर मॉडल का अर्थ है। उदाहरण के लिए, बिक्री के संदर्भ में "ग्राहक" और सहायता के संदर्भ में "ग्राहक" अलग-अलग संस्थाएँ हैं।
\n
• Entity (इकाई) — एक अद्वितीय पहचानकर्ता वाली वस्तु जो समय के साथ बदलती है।
\n
• Value Object (मूल्य वस्तु) — एक अपरिवर्तनीय वस्तु जो अपनी विशेषताओं द्वारा परिभाषित होती है, न कि पहचानकर्ता द्वारा।
\n
• Aggregate (समुच्चय) — संबंधित वस्तुओं का एक समूह जिसे एक इकाई के रूप में माना जाता है।
\n
• Repository (भंडार) — डेटा तक पहुँच के लिए एक अमूर्तता जो भंडारण विवरणों को छिपाती है।
\n

अमूर्त लगता है? अब इसे Kotlin में अनुवाद करते हैं।

Kotlin पर Value Objects: लालित्य और सुरक्षा

चलिए सबसे सुखद चीज़ से शुरू करते हैं — Value Objects (VO)। Kotlin में, data class के कारण इन्हें लागू करना एक खुशी की बात है।

कल्पना करें कि हम एक होटल बुकिंग सिस्टम पर काम कर रहे हैं। हमारे पास "ठहरने की अवधि" की अवधारणा है। यह कोई इकाई नहीं है — यह सिर्फ तारीखों का एक सेट है। VO के लिए एक आदर्श उम्मीदवार।

data class StayPeriod(\n    val checkIn: LocalDate,\n    val checkOut: LocalDate\n) {\n    init {\n        require(checkIn.isBefore(checkOut)) {\n            "चेक-इन की तारीख चेक-आउट की तारीख से पहले होनी चाहिए"\n        }\n    }\n\n    val totalNights: Int\n        get() = ChronoUnit.DAYS.between(checkIn, checkOut).toInt()\n\n    fun overlapsWith(other: StayPeriod): Boolean {\n        return !(this.checkOut.isBefore(other.checkIn) || this.checkIn.isAfter(other.checkOut))\n    }\n}

यह क्यों अच्छा है?

\n
• अपरिवर्तनीयता — सभी फ़ील्ड val हैं। कोई गलती से चेक-इन की तारीख नहीं बदलेगा।
\n
• अंतर्निहित मान्यता — init ब्लॉक सुनिश्चित करता है कि वस्तु केवल सही स्थिति में ही बनाई जाए।
\n
• व्यवहार — overlapsWith विधि व्यावसायिक नियम को समाहित करती है। आप सेवाओं में तारीखों का ओवरलैप नहीं ढूंढते, बल्कि वस्तु से ही पूछते हैं।
\n

DDD में, हम इसे समृद्ध मॉडल कहते हैं — वस्तु केवल डेटा संग्रहीत नहीं करती, बल्कि व्यावसायिक संचालन करने में सक्षम है।

Entity: जब पहचान महत्वपूर्ण हो

अब Entity पर आते हैं। VO के विपरीत, इकाई बदलती है और इसकी एक पहचान होती है। Kotlin में, हम एक सामान्य क्लास का उपयोग करते हैं, लेकिन पहचानकर्ता पर जोर देते हैं।

उदाहरण — होटल में बुकिंग (Booking):

class Booking(\n    val id: BookingId,\n    val roomNumber: Ro