Swift में हेक्सागोनल आर्किटेक्चर: बिना निर्भरता के शुद्ध लॉजिक

शुरुआती लोगों के लिए ऑनलाइन Python प्रशिक्षक

Python आसानी से सीखें बिना सिद्धांत के बोझ के। स्वचालित जांच के साथ व्यावहारिक कार्य हल करें और ब्राउज़र में सीधे कोड लिखें।

पाठ्यक्रम शुरू करें

जब MVVM और MVC बचाना बंद कर देते हैं, और परीक्षण नरक बन जाते हैं

\n\n

क्या आपने कभी Swift में कोई ऐप लिखा है, जहाँ छह महीने बाद एक फीचर जोड़ने से तीन अन्य टूट जाते हैं, और परीक्षणों को पूरी तरह से फिर से लिखना पड़ता है क्योंकि डेटाबेस Core Data से Realm में बदल गया? यदि हाँ — तो आप अकेले नहीं हैं। क्लासिकल लेयर्ड आर्किटेक्चर (MVC, MVVM) शुरुआत में बढ़िया काम करते हैं, लेकिन प्रोजेक्ट बढ़ने पर 'गड़बड़' बन जाते हैं।

\n\n

मैं आपको हेक्सागोनल आर्किटेक्चर (जिसे Ports & Adapters भी कहा जाता है) दिखाऊंगा — यह एक दृष्टिकोण है जो Java और DDD की दुनिया से आया है, लेकिन Swift पर पूरी तरह से फिट बैठता है। हम इसे वास्तविक उदाहरणों के साथ समझेंगे, बिना अमूर्त 'User' और 'Manager' के। आप देखेंगे कि कैसे बिज़नेस लॉजिक को डेटाबेस, UI और नेटवर्क से अलग किया जाए ताकि उन्हें बदला जा सके, बिना एप्लिकेशन के कोर को छुए।

\n\n

यह कोई और सिद्धांत नहीं है — यह व्यावहारिक ज्ञान है जिसे आप आज ही अपने प्रोजेक्ट में लागू कर सकते हैं।

\n\n

हेक्सागोनल आर्किटेक्चर क्या है? सरल शब्दों में

\n\n

एक षट्भुज (हेक्सागोन) की कल्पना करें (इसीलिए यह नाम है)। केंद्र में आपका शुद्ध बिज़नेस लॉजिक (डोमेन) है। किनारों पर पोर्ट (इंटरफेस) हैं, जिनके माध्यम से बाहरी दुनिया कोर से संवाद करती है। एडेप्टर विशिष्ट कार्यान्वयन हैं: डेटाबेस, API, UI, फ़ाइल सिस्टम।

\n\n

मुख्य नियम: कोर को बाहरी दुनिया के बारे में कुछ नहीं पता। न UIKit के बारे में, न URLSession के बारे में, न Core Data के बारे में। यह केवल अपने इंटरफेस (पोर्ट) के बारे में जानता है।

\n\n

जीवन से एक उदाहरण: एक ऑनलाइन स्टोर की कल्पना करें। कोर जानता है कि 'कार्ट' और 'ऑर्डर दें' है। उसे इससे कोई फर्क नहीं पड़ता कि डेटा कहाँ से आता है — वेबसॉकेट से, लोकल JSON से या कीबोर्ड से। एडेप्टर पोर्ट से जुड़ते हैं और बाहरी सिग्नल को डोमेन कमांड में अनुवाद करते हैं।

\n\n

Swift प्रोजेक्ट्स में इसका उपयोग क्यों करें?

\n\n
    \n
  • परीक्षण योग्यता — आप वास्तविक डेटाबेस और नेटवर्क के बिना डोमेन का परीक्षण करते हैं। बस एडेप्टर को मॉक से बदल दें।
  • \n
  • लचीलापन — Firebase से अपने सर्वर पर जाना चाहते हैं? एक एडेप्टर बदलें, आधा एप्लिकेशन नहीं।
  • \n
  • पठनीयता — बिज़नेस लॉजिक ViewController में बिखरा नहीं है। यह एक जगह पर है।
  • \n
  • फ्रेमवर्क से स्वतंत्रता — आपका कोर UIKit, Combine या Alamofire को इम्पोर्ट नहीं करता।
  • \n
\n\n

Swift में हेक्सागोनल आर्किटेक्चर पर प्रोजेक्ट संरचना

\n\n

चलिए सीधे कोड पर आते हैं। मान लीजिए हम कार्य प्रबंधन (Todo list) के लिए एक ऐप लिख रहे हैं। फ़ोल्डर संरचना इस प्रकार होगी:

\n\n
App/\n├── Domain/\n│   ├── Entity/\n│   │   └── Task.swift\n│   ├── UseCase/\n│   │   └── CreateTaskUseCase.swift\n│   └── Port/\n│       ├── TaskRepository.swift\n│       └── TaskOutputPort.swift\n├── Adapter/\n│   ├── Persistence/\n│   │   └── CoreDataTaskRepository.swift\n│   ├── Network/\n│   │   └── APITaskRepository.swift\n│   └── Presentation/\n│       └── TaskListViewModel.swift\n└── Main/\n    └── AppDelegate.swift
\n\n

ध्यान दें: Domain Foundation के अलावा कुछ भी इम्पोर्ट नहीं करता। Adapter CoreData, UIKit, Alamofire — जो चाहे इम्पोर्ट कर सकता है।

\n\n

चरण 1: डोमेन एंटिटी और पोर्ट

\n\n

सबसे महत्वपूर्ण से शुरू करते हैं — डोमेन मॉडल। यह struct या enum है जो बिज़नेस एंटिटी का वर्णन करता है। कोई NSManagedObject नहीं, कोई Codable नहीं।

\n\n
// Domain/Entity/Task.swift\nstruct Task {\n    let id: UUID\n    var title: String\n    var isCompleted: Bool\n    let createdAt: Date\n}
\n\n

अब रिपॉजिटरी के लिए पोर्ट (आउटपुट पोर्ट) परिभाषित करते हैं। यह एक प्रोटोकॉल है जो बताता है कि हम कार्यों को कैसे सहेजते और लोड करते हैं।

\n\n
// Domain/Port/TaskRepository.swift\nprotocol TaskRepository {\n    func fetchAll() async throws -> [Task]\n    func save(task: Task) async throws\n    func delete(taskID: UUID) async throws\n}
\n\n

और इनपुट पोर्ट — जिसके माध्यम से बाहरी दुनिया (UI, API) कोर के साथ इंटरैक्ट करती है। आमतौर पर यह UseCase होता है।

\n\n
// Domain/Us                

ब्लॉग

पुस्तक अनुशंसाएँ