Python के साथ आर्किटेक्चर पैटर्न को समझना

• जटिल Python एप्लिकेशन का आकार बढ़ने पर सिर्फ सरल implementation के सहारे testing और बदलाव संभालना मुश्किल हो जाता है, और यह किताब उसके समाधान के रूप में architecture patterns को code examples के साथ समझाती है
• MADE.com की online furniture sales और global supply chain को उदाहरण बनाकर, वास्तविक operational समस्याओं को software model में बदलने वाली domain modeling को केंद्र में रखा गया है
• इसके मुख्य स्तंभ TDD, DDD, और event-driven architecture हैं, जिनका लक्ष्य तेज unit tests, कम संख्या में E2E tests, infrastructure से अलग models, और message-based integration है
• इसमें Flask, SQLAlchemy, pytest, Docker, Redis का उपयोग होता है, लेकिन फोकस ऐसी संरचना बनाने पर है जहाँ किसी खास technology choice को implementation detail के स्तर पर पीछे धकेला जा सके
• अगर आपने जटिल Python applications के साथ काम किया है तो आप इसे पढ़ सकते हैं; DDD या पारंपरिक application architecture patterns की पहले से जानकारी जरूरी नहीं है

---

टेस्ट करना आसान हो ऐसी संरचना से शुरू हुई समस्या-चेतना

• Harry की पिछली किताब Test-Driven Development with Python के बाद यह सवाल बचा रह गया कि application को कैसे structure किया जाए ताकि उसे test करना आसान हो
• मूल बात यह है कि business logic का पर्याप्त हिस्सा unit tests से कवर हो, और integration tests तथा E2E tests की संख्या न्यूनतम रखी जा सके
• "Hexagonal Architecture", "Ports and Adapters", "Functional Core, Imperative Shell" जैसे concepts का उल्लेख हुआ था, लेकिन उस समय उन्हें वास्तव में पर्याप्त गहराई से समझा या लागू नहीं किया गया था
• Bob टीम में software architecture संभालने वाला कोई न होने के कारण architect बने, और Ian Cooper से code लिखने और सोचने के नए तरीके सीखे

MADE.com का उदाहरण: supply chain को software के रूप में model करना

• दोनों लेखक यूरोपीय ecommerce कंपनी MADE.com में काम करते हुए, इस किताब की तकनीकों को वास्तविक business problems को model करने वाले distributed systems बनाने में लागू कर चुके हैं
• example domain, Bob द्वारा MADE में बनाए गए पहले system पर आधारित है, और इसका उद्देश्य उन बातों को व्यवस्थित करना था जिन्हें नए programmers के टीम में जुड़ने पर सिखाना पड़ता है
• MADE.com freight partners और manufacturers से बनी global supply chain चलाता है
  • लागत कम रखने के लिए वह shipping को इस तरह optimize करना चाहता है कि inventory लंबे समय तक warehouse में पड़ी न रहे
  • आदर्श रूप से, जिस दिन ग्राहक sofa खरीदे उसी दिन वह port पर पहुँचे और बिना storage के सीधे ग्राहक के घर भेज दिया जाए
  • container ship से सामान आने में 3 महीने तक लग सकते हैं, इसलिए timing को साधना मुश्किल होता है
• वास्तविक operations में damage, पानी भर जाना, तूफान के कारण delay, logistics partners की handling errors, documents की कमी, और ग्राहकों द्वारा order changes जैसे कई variables लगातार आते रहते हैं
• इन समस्याओं से निपटने के लिए वास्तविक दुनिया के operations को software में व्यक्त करके, जितना संभव हो उतना काम automate करने की कोशिश की जाती है

Python projects बड़े होने पर दिखने वाली सीमाएँ

• Python ने तेज़ी से विकास किया है और mature हुआ है, लेकिन लेखकों के अनुसार अब यह उन समस्याओं को गंभीरता से संभालना शुरू कर रहा है जिन्हें C# और Java ecosystem लंबे समय से हल करते आए हैं
• startups अब वास्तविक business बन रहे हैं, और web apps तथा script automation बढ़कर enterprise software का रूप ले रहे हैं
• Python की philosophy में “There should be one—and preferably only one—obvious way to do it” शामिल है, लेकिन project का आकार बढ़ने पर सबसे obvious तरीका हमेशा complexity और बदलती requirements को संभालने के लिए उपयुक्त नहीं होता
• किताब में शामिल techniques और patterns नए नहीं हैं, लेकिन Python जगत में वे अभी भी अपेक्षाकृत नए माने जा सकते हैं
• यह किताब Eric Evans की Domain-Driven Design या Martin Fowler की Patterns of Enterprise Application Architecture का विकल्प बनने की कोशिश नहीं करती; बल्कि उन classics का बार-बार संदर्भ देती है और उन्हें पढ़ने की सलाह भी देती है
• मौजूदा साहित्य के code examples अक्सर Java या C++/# में लिखे गए हैं, इसलिए Python developers के लिए उन्हें पढ़ना थोड़ा कठिन हो सकता है

जटिलता प्रबंधन के लिए तीन औज़ार

• Test-Driven Development (TDD) सही code बनाने में मदद करता है, और regression के डर के बिना refactor करने या features जोड़ने की सुविधा देता है
  • tests को यथासंभव तेज़ चलाने के तरीके
  • तेज़ और dependency-free unit tests से अधिकतम coverage और feedback लेने के तरीके
  • धीमे और अस्थिर E2E tests को न्यूनतम रखने के तरीके समझाए गए हैं
• Domain-Driven Design (DDD) business domain का अच्छा model बनाने पर ध्यान केंद्रित कराता है
  • model को infrastructure concerns में उलझने से कैसे बचाया जाए
  • model को बदलने में कठिन होने से कैसे रोका जाए, यह भी बताया गया है
• messages के जरिए integrated loosely coupled microservices, जिन्हें कभी-कभी reactive microservices भी कहा जाता है, कई applications या business domains के बीच की complexity को संभालने का एक तरीका माने गए हैं
  • Python ecosystem के मौजूदा tools जैसे Flask, Django, Celery के साथ इन्हें कैसे फिट किया जाए, यह हमेशा स्पष्ट नहीं होता
• भले ही आप microservices का उपयोग न करते हों या उनमें रुचि न रखते हों, किताब के अधिकांश patterns और event-driven architecture का बड़ा हिस्सा monolithic architecture पर भी लागू किया जा सकता है

पाठक और पूर्वज्ञान

• यह किताब मानकर चलती है कि पाठक ने कुछ हद तक जटिल Python applications को करीब से संभाला है
• यह खास तौर पर उन पाठकों के लिए है जिन्होंने complexity management की पीड़ा महसूस की है
• DDD या पारंपरिक application architecture patterns के बारे में पहले से जानकारी जरूरी नहीं है
• व्याख्या chapter दर chapter, example application को केंद्र में रखकर आगे बढ़ती है
• लेखक अपने काम में TDD का उपयोग करते हैं, इसलिए वे अक्सर पहले test code दिखाते हैं और फिर implementation
• Flask, SQLAlchemy, pytest, Docker, Redis का उपयोग किया गया है, लेकिन उनसे परिचित होना सहायक है, अनिवार्य नहीं
• मुख्य लक्ष्यों में से एक ऐसी architecture बनाना है जिसमें खास technology choices सिर्फ छोटी implementation details बनकर रह जाएँ

किताब की संरचना

• किताब दो हिस्सों में बंटी है

• भाग 1: domain modeling को support करने वाली architecture

  • domain modeling और DDD पर अध्याय 1, 2, और 7 में चर्चा होती है
  • आधार यह है कि जटिल business problems को code के भीतर domain model के रूप में व्यक्त किया जाना चाहिए
  • यह समझाया गया है कि बिना external dependencies और तेज़ unit tests वाले model से शुरुआत कैसे की जाए
  • इसके बाद सही aggregate चुनने और data integrity की समस्याओं पर फिर से चर्चा होती है
  • Repository, Service Layer, Unit of Work patterns पर अध्याय 2, 4, और 5 में चर्चा होती है
  • ये patterns model को अनावश्यक dependencies से अलग रखने के लिए एक-दूसरे का पूरक काम करते हैं
  • persistence store के आसपास abstraction layer बनाई जाती है, और system entry points तथा मुख्य use cases को capture करने वाली service layer रखी जाती है
  • यह ऐसी संरचना दिखाता है जिसमें Flask API या CLI जैसे thin entry points बनाना आसान हो
  • abstraction और testing पर चर्चा अध्याय 3 और 5 में आगे बढ़ती है
  • Repository pattern के परिचय के बाद abstraction चुनने के तरीके और coupling में abstraction की भूमिका पर चर्चा की जाती है
  • Service Layer pattern के बाद test pyramid और यथासंभव ऊँचे abstraction level पर unit tests लिखने के तरीके समझाए जाते हैं

• भाग 2: event-driven architecture

  • event-driven architecture पर अध्याय 8 से 11 तक चर्चा होती है
  • Domain Events, Message Bus, Handler patterns का परिचय दिया जाता है
  • Domain Events यह व्यक्त करने का माध्यम हैं कि system में कोई interaction किसी दूसरी action को trigger करता है
  • Message Bus actions को events trigger करने और उपयुक्त handler को call करने में सक्षम बनाता है
  • यह भी बताया गया है कि events को microservice architecture में services के बीच integration pattern की तरह कैसे इस्तेमाल किया जा सकता है
  • commands और events में अंतर किया जाता है, और application मूलतः message-processing system बन जाता है
  • अध्याय 12 में CQRS का उदाहरण events का उपयोग करने और बिना उपयोग करने—दोनों तरीकों से दिया गया है
  • अध्याय 13 में explicit और implicit dependencies को व्यवस्थित करके एक सरल dependency injection framework implement किया जाता है
  • epilogue में बिल्कुल नई simple example से नहीं, बल्कि मौजूदा software पर इन सिद्धांतों को कैसे लागू किया जाए और आगे क्या पढ़ा जाए, यह बताया गया है

example code और साथ-साथ अभ्यास

• किताब एक ही example project के इर्द-गिर्द बनी है, और chapters के आगे बढ़ने के साथ project को चरणबद्ध तरीके से विस्तारित किया जाता है
• लेखक इस बात को महत्वपूर्ण मानते हैं कि पाठक वास्तव में code को छूकर देखें और महसूस करें कि patterns कैसे काम करते हैं
• सारा code GitHub पर उपलब्ध है और हर chapter के लिए अलग branch है
  • branches की सूची GitHub की branches page पर देखी जा सकती है
• साथ-साथ सीखने के लिए तीन तरीके सुझाए गए हैं
  • अपना repository बनाकर किताब के examples के अनुसार app तैयार करें, और जरूरत पड़ने पर लेखकों के repository को देखें
  • हर pattern को chapter के हिसाब से अपने छोटे project पर लागू करके देखें
  • हर chapter के "Exercise for the Reader" और आंशिक रूप से खाली GitHub code का उपयोग करके जल्दी अभ्यास करें
• खास तौर पर वे पाठक जो अपने project पर patterns लागू करना चाहते हैं, उनके लिए पहले simple examples पर काम करना सुरक्षित अभ्यास है
• कम-से-कम हर chapter पढ़ते समय repository में git checkout से code लेकर, उसे एक वास्तविक काम करने वाले app के संदर्भ में देखने की सलाह दी गई है

लाइसेंस और प्रारूप

• code और online version Creative Commons CC BY-NC-ND license के अंतर्गत हैं
  • noncommercial उपयोग
  • attribution आवश्यक
  • copy और share करने की अनुमति
• print edition अलग license के अंतर्गत आती है, और reuse को लेकर चिंता हो तो O’Reilly से संपर्क करने को कहा गया है
• किताब की typographic conventions में italic, fixed-width, fixed-width bold, और fixed-width italic का अलग-अलग उपयोग किया गया है
  • italic नए terms, URL, email addresses, filenames, और extensions को दर्शाता है
  • fixed-width program listings और code elements को दर्शाता है
  • fixed-width bold उन commands या text के लिए है जिन्हें user को ज्यों का त्यों टाइप करना है
  • fixed-width italic उस text के लिए है जिसे user द्वारा दिए गए या context के अनुसार तय मान से बदलना होता है

[xguru]

इसका कोरियाई संस्करण उपलब्ध है पायथन से समझे गए आर्किटेक्चर पैटर्न