जटिल Swift प्रोजेक्ट्स के लिए CQRS और Event Sourcing आर्किटेक्चर

पारंपरिक आर्किटेक्चर आधुनिक समस्याओं का समाधान क्यों नहीं कर पाता?

क्या आपने कभी ऐसी स्थिति का सामना किया है जहाँ Swift ऐप में एक नई सुविधा जोड़ना एक बुरा सपना बन जाता है? बग्स की बाढ़ आ जाती है, डेटा खो जाता है, और लॉजिक इतना बढ़ जाता है कि संभालना मुश्किल हो जाता है? परिचित लग रहा है? तो आपका स्वागत है उस दुनिया में जहाँ CQRS और Event Sourcing आपके सबसे अच्छे दोस्त बन जाते हैं।

ये पैटर्न सिर्फ फैंसी शब्द नहीं हैं। ये एक सोचने का तरीका है जो Swift में ऐप्लिकेशन बनाने के दृष्टिकोण को पूरी तरह से बदल देता है। और आज हम इन्हें वास्तविक उदाहरणों के साथ समझेंगे। बिना किसी फालतू बात के, बिना उबाऊ थ्योरी के - सिर्फ प्रैक्टिकल ज्ञान।

CQRS क्या है? बांटो और राज करो

CQRS (Command Query Responsibility Segregation) एक सिद्धांत है जो कहता है: "एक ही क्लास में पढ़ने और लिखने के काम को मत मिलाओ"। यह सुनने में सरल लगता है, लेकिन इसके परिणाम बहुत बड़े हैं।

पारंपरिक CRUD (Create, Read, Update, Delete) आर्किटेक्चर में, आप सब कुछ के लिए एक ही मॉडल का उपयोग करते हैं। जैसे, User। यही मॉडल सेव होता है, पढ़ा जाता है, और अपडेट किया जाता है। लेकिन क्या होगा अगर पढ़ने के लिए अलग फील्ड्स चाहिए और लिखने के लिए अलग? तब शुरू होते हैं कोस्टाइल्स: ऑप्शनल फील्ड्स, फ्लैग्स, मैपिंग्स...

CQRS जिम्मेदारी को अलग करने का सुझाव देता है:

\n
• कमांड्स (Commands) — स्थिति को बदलते हैं। ये डेटा को म्यूटेट करते हैं, लेकिन कुछ भी रिटर्न नहीं करते।
\n
• क्वेरीज़ (Queries) — डेटा पढ़ते हैं। ये स्थिति नहीं बदलते, सिर्फ रिजल्ट लौटाते हैं।
\n

Swift में यह कुछ इस तरह दिख सकता है:

// कमांड — सिर्फ म्यूटेशन\nstruct CreateUserCommand {\n    let id: UUID\n    let name: String\n    let email: String\n}\n\n// क्वेरी — सिर्फ पढ़ना\nstruct GetUserQuery {\n    let userId: UUID\n}\n\n// कमांड हैंडलर\nclass CreateUserCommandHandler {\n    func handle(_ command: CreateUserCommand) {\n        // यूज़र बनाने की लॉजिक\n        print("यूज़र बनाया गया: \\(command.name)")\n    }\n}\n\n// क्वेरी हैंडलर\nclass GetUserQueryHandler {\n    func handle(_ query: GetUserQuery) -> User? {\n        // यूज़र प्राप्त करने की लॉजिक\n        return User(id: query.userId, name: "राहुल", email: "rahul@example.com")\n    }\n}

देखा? कोई मिलावट नहीं। हर क्लास सिर्फ एक काम करता है। इससे टेस्टिंग, मेंटेनेंस और स्केलिंग आसान हो जाती है।

Event Sourcing: स्थिति नहीं, इतिहास स्टोर करें

अब बात करते हैं Event Sourcing की — यह एक पैटर्न है जो ऑब्जेक्ट की मौजूदा स्थिति को नहीं, बल्कि उस स्थिति तक पहुँचाने वाली सभी घटनाओं (events) के क्रम को स्टोर करता है।

एक बैंक खाते की कल्पना करें। बैलेंस (1000 रुपये) स्टोर करने के बजाय, आप घटनाओं की एक सूची स्टोर करते हैं: "खाता खोला गया", "500 जमा किए गए", "200 निकाले गए", "700 जमा किए गए"। मौजूदा बैलेंस जानने के लिए, आप बस सभी घटनाओं को दोबारा चलाते हैं। यह अविश्वसनीय संभावनाएं देता है: ऑडिट, बदलावों को वापस लेना, एनालिटिक्स।

आइए इसे Swift में लागू करें:

// इवेंट\nprotocol Event {}\n\nstruct AccountCreated: Event {\n    let accountId: UUID\n    let initialBalance: Double\n}\n\nstruct MoneyDeposited: Event {\n    let accountId: UUID\n    let amount: Double\n}\n\nstruct MoneyWithdrawn: Event {\n    let accountId: UUID\n    let amount: Double\n}\n\n// एग्रीगेट — इवेंट्स से स्थिति को पुनर्स्थापित करता है\nclass BankAccount {\n    private(set) var balance: Double = 0\n    private(set) var isActive: Bool = false\n    private(set) var accountId: UUID?\n\n    func apply(_ event: Event) {\n        switch event {\n        case let created as AccountCreated:\n            accountId = created.accountId\n            balance = created.initialBalance\n            isActive = true\n        case let deposited as MoneyDeposited:\n            balance += deposited.amount\n        case let withdrawn as MoneyWithdrawn:\n            balance -= withdrawn.amount\n        default:\n            break\n        }\n    }\n\n    // इवेंट हिस्ट्री से पुनर्स्थापित करना\n    static func load(from history: [Event]) -> BankAccount {\n        l