C++ में हेक्सागोनल आर्किटेक्चर: बिना दर्द के कोड की शुद्धता

C++ में हेक्सागोनल आर्किटेक्चर: बदलावों से डरना कैसे बंद करें और टेस्ट से प्यार करें

क्या आपने कभी डेटाबेस मॉड्यूल को फिर से लिखा है और फिर महसूस किया है कि आपको आधी बिजनेस लॉजिक बदलनी पड़ रही है? या क्या आपने कभी किसी ऐसे क्लास को यूनिट टेस्ट से कवर करने की कोशिश की है जो बाहरी दुनिया से तीन टन डिपेंडेंसी खींचता है? यदि हाँ — तो क्लब में आपका स्वागत है। सौभाग्य से, हमारे पास एक उपकरण है जो इन समस्याओं को हमेशा के लिए हल करता है: हेक्सागोनल आर्किटेक्चर (जिसे Ports & Adapters आर्किटेक्चर भी कहा जाता है)।

इस लेख में, हम देखेंगे कि इस शक्तिशाली अवधारणा को C++ में कैसे लागू किया जाए। आप अमूर्त आरेख नहीं, बल्कि वास्तविक कोड देखेंगे जिसका उपयोग आप अभी कर सकते हैं। और हाँ, हम इसे बिना कट्टरता के करेंगे — ताकि न तो लीगेसी प्रोजेक्ट फटे और न ही नया कोड गंदा हो।

हेक्सागोनल आर्किटेक्चर क्या है (और इसमें षट्भुज का क्या)?

अपने एप्लिकेशन के कोर की कल्पना करें — यह शुद्ध बिजनेस लॉजिक है जो न तो डेटाबेस के बारे में जानता है, न REST API के बारे में, न ही ग्राफिकल इंटरफ़ेस के बारे में। इस कोर के चारों ओर पोर्ट (इंटरफ़ेस) स्थित होते हैं, और उससे भी आगे एडेप्टर (विशिष्ट कार्यान्वयन) होते हैं। दृश्य रूप से यह एक षट्भुज (हेक्सागोन) जैसा दिखता है, इसलिए इसका नाम पड़ा।

मुख्य विचार: डिपेंडेंसी अंदर की ओर निर्देशित होती हैं। बाहरी दुनिया कोर पर निर्भर करती है, न कि इसके विपरीत। यह आपको बिजनेस लॉजिक को बदले बिना डेटाबेस, संचार प्रोटोकॉल या UI बदलने की अनुमति देता है। यह एक सपने जैसा लगता है? आइए देखें कि इसे C++ में कैसे लागू किया जाए।

क्लासिक समस्या: टाइट कपलिंग

यहाँ बताया गया है कि विशिष्ट C++ कोड अक्सर कैसा दिखता है:

class OrderService {\npublic:\n    void createOrder(const OrderData& data) {\n        // बिजनेस लॉजिक\n        if (data.items.empty()) throw std::runtime_error("ऑर्डर खाली है");\n\n        // और यहाँ समस्या है — डेटाबेस पर सीधी निर्भरता\n        Database db("localhost", 5432);\n        db.connect();\n        db.saveOrder(data);\n        db.disconnect();\n        \n        // और ईमेल-सर्विस पर भी\n        EmailSender sender("smtp.example.com");\n        sender.sendInvoice(data);\n    }\n};

यहाँ क्या गलत है? सब कुछ। आप वास्तविक DB और मेल सर्वर के बिना createOrder का परीक्षण नहीं कर सकते। यदि कल आप PostgreSQL से MongoDB पर स्विच करने का निर्णय लेते हैं — तो आपको OrderService को फिर से लिखना होगा। और यदि ईमेल-सर्विस क्यू के माध्यम से एसिंक्रोनस हो जाती है — तो फिर से बिजनेस लॉजिक में बदलाव।

हेक्सागोनल आर्किटेक्चर के साथ समस्या का समाधान

चरण 1: पोर्ट (इंटरफ़ेस) परिभाषित करें

पोर्ट एक अनुबंध है जो परिभाषित करता है कि कोर को बाहरी दुनिया से क्या चाहिए, लेकिन यह नहीं कि इसे कैसे लागू किया गया है।

// port/OrderRepository.h\nclass OrderRepository {\npublic:\n    virtual ~OrderRepository() = default;\n    virtual void save(const Order& order) = 0;\n    virtual std::optional<Order> findById(const std::string& id) = 0;\n};\n\n// port/NotificationService.h\nclass NotificationService {\npublic:\n    virtual ~NotificationService() = default;\n    virtual void sendInvoice(const Order& order) = 0;\n};

ध्यान दें: ये शुद्ध अमूर्त क्लास हैं। फ्रेमवर्क, लाइब्रेरी या बाहरी सेवाओं पर कोई निर्भरता नहीं। केवल बिजनेस एंटिटीज़।

चरण 2: कोर (बिजनेस लॉजिक) लिखें

अब हमारी सेवा केवल इंटरफ़ेस पर निर्भर करती है, विशिष्ट कार्यान्वयन पर नहीं:

// core/OrderService.h\nclass OrderService {\npublic:\n    OrderService(OrderRepository& repo, NotificationService& notifier)\n        : repository_(repo), notifier_(notifier) {}\n\n    void createOrder(const OrderData& data) {\n        // वैलिडेशन — शुद्ध बिजनेस लॉजिक\n        if (data.items.empty()) {\n            throw std::invalid_argument("ऑर्डर खाली नहीं हो सकता");\n        }\n\n        Order order = Order::create(data);\n        repository_.save(order);\n        notifier_.sendInvoice(order);\n    }\n\nprivate:\n    OrderRepository& repository_;\n    NotificationServ