Go में Domain-Driven Design: एब्स्ट्रैक्शन की परतों में न उलझें

परिचय: आपके Go प्रोजेक्ट को DDD की आवश्यकता क्यों है?

क्या आपने कभी Go में कोई सर्विस लिखी है जो कुछ एंडपॉइंट्स और तीन डेटाबेस टेबल से शुरू हुई, और छह महीने बाद handler.go फ़ाइलों और कोड में बिखरे जादुई नंबरों का एक राक्षस बन गई? परिचित लगता है? मैं भी इससे गुज़रा हूँ।

क्लासिक Go डेवलपमेंट की समस्या यह है कि हम डेटाबेस और JSON के बारे में बहुत जल्दी सोचते हैं, और मुख्य चीज़ को भूल जाते हैं: बिज़नेस लॉजिक। Domain-Driven Design (DDD) ठीक उसी समय मदद करता है जब आप अराजकता में व्यवस्था लाना चाहते हैं। लेकिन Go पर DDD को कैसे लागू करें, जब भाषा हमें क्लासेस और इनहेरिटेंस नहीं देती? आइए समझते हैं।

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

DDD क्या है और Go डेवलपर को इसकी आवश्यकता क्यों है?

Domain-Driven Design तकनीक के बारे में नहीं है। यह भाषा के बारे में है। यह इस बारे में है कि कोड बिज़नेस की भाषा बोले। यदि आपका विषय क्षेत्र ऑनलाइन स्टोर है, तो कोड में Order, Product, Cart होना चाहिए, न कि DataTransferObject और EntityManager।

Go, अपनी सादगी और जादू की कमी के साथ, DDD के लिए एकदम सही है। यहाँ कोई प्रॉक्सी क्लासेस या रिफ्लेक्शन नहीं है जो सार को छिपाते हैं। Go में आपको ईमानदार होने के लिए मजबूर किया जाता है: यदि आपके पास कोई एग्रीगेट है, तो वह एक स्पष्ट स्ट्रक्चर है; यदि कोई रिपॉजिटरी है, तो वह एक इंटरफ़ेस है।

DDD के मुख्य बिल्डिंग ब्लॉक जिन्हें हम देखेंगे:

\n
• Entity (एंटिटी) — एक अद्वितीय पहचानकर्ता वाली वस्तु (जैसे, User)।
\n
• Value Object (वैल्यू ऑब्जेक्ट) — अपरिवर्तनीय वस्तु जो विशेषताओं का वर्णन करती है (जैसे, Address)।
\n
• Aggregate (एग्रीगेट) — एंटिटीज़ का एक समूह जो स्थिरता सुनिश्चित करता है (जैसे, Order और OrderItem)।
\n
• Repository (रिपॉजिटरी) — वस्तुओं का संग्रह जो स्टोरेज विवरण छुपाता है।
\n
• Domain Service (डोमेन सर्विस) — एक ऑपरेशन जो एक एंटिटी में फिट नहीं बैठता।
\n

अब इसे Go में अनुवाद करते हैं।

प्रोजेक्ट संरचना: फ़ोल्डर्स में कैसे न भटकें

अच्छी खबर: Go कोई संरचना नहीं थोपता। बुरी खबर: संरचना के बिना आप जल्दी डूब जाएंगे। Go में DDD के लिए, मैं निम्नलिखित कोड संगठन की सलाह देता हूँ:

your-project/\n├── cmd/\n│   └── server/\n│       └── main.go\n├── internal/\n│   ├── domain/          # शुद्ध कोर: एंटिटीज़, नियम\n│   │   ├── order.go\n│   │   ├── product.go\n│   │   └── errors.go\n│   ├── application/     # Use cases / एप्लिकेशन सर्विसेज़\n│   │   ├── order_service.go\n│   │   └── product_service.go\n│   └── infrastructure/  # डेटाबेस, बाहरी API, HTTP हैंडलर\n│       ├── postgres/\n│       │   └── order_repository.go\n│       └── http/\n│           └── handler.go\n└── go.mod

ध्यान दें: domain infrastructure को इम्पोर्ट नहीं करता। यह DDD का सुनहरा नियम है — डोमेन को डेटाबेस और HTTP के बारे में कुछ नहीं पता। वह शुद्ध स्ट्रक्चर और इंटरफ़ेस के वैक्यूम में रहता है।

डोमेन लिखना: Order और Value Objects

कोर से शुरू करते हैं। मान लीजिए हम ऑर्डर प्रबंधन प्रणाली बना रहे हैं। यहाँ बताया गया है कि Order एंटिटी कैसी दिख सकती है:

// internal/domain/order.go\npackage domain\n\nimport (\n    "errors"\n    "time"\n)\n\ntype OrderStatus string\n\nconst (\n    OrderStatusPending   OrderStatus = "pending"\n    OrderStatusConfirmed OrderStatus = "confirmed"\n    OrderStatusCancelled OrderStatus = "cancelled"\n)\n\ntype OrderID string\n\ntype Order struct {\n    ID         OrderID\n    CustomerID string\n    Items      []OrderItem\n    Status     OrderStatus\n    CreatedAt  time.Time\n    Upd