- यह तर्क है कि software development की ज़्यादातर मुख्य कठिन समस्याएँ कोड के अंदर नहीं, बल्कि कोड और कोड, सिस्टम और सिस्टम के मिलने वाले Boundary पर पैदा होती हैं
- Boundary = वह बिंदु जहाँ अलग-अलग concerns, responsibilities और contexts मिलते हैं
- फ़ंक्शन अलग करना, modularization, microservices आदि विकास के लगभग हर काम का मतलब Boundary बनाना है
- विडंबना यह है: हम complexity को संभालने के लिए Boundary बनाते हैं, लेकिन Boundary खुद नई complexity का स्रोत बन जाती है
कोड में बनने वाले Boundary
- caller-callee Boundary:
null return करना बनाम exception throw करना जैसे contracts की अस्पष्टता
- interface Boundary: abstraction leakage का नियम — छिपाई गई complexity कभी न कभी Boundary को तोड़कर ऊपर आ जाती है
- dependency Boundary: external API और libraries बिना चेतावनी बदल सकती हैं
- transformation Boundary: object-relational impedance mismatch की तरह, Boundary पार करते समय हर बार information distortion या loss
- trust Boundary: verified data बनाम unverified data की सीमा → बिना signature वाले webhook receive करने जैसी security vulnerabilities
- design-implementation Boundary: requirements → design → implementation → operations, हर चरण में information loss जमा होता जाता है
भौतिक Boundary
- ordering Boundary: asynchronous points के बीच state बदल सकती है, distributed systems में यह और गंभीर होता है
- scale Boundary: threshold पार होने पर मात्रात्मक नहीं बल्कि गुणात्मक बदलाव होते हैं
- environment Boundary: “मेरे कंप्यूटर पर तो ठीक चल रहा है” जैसी स्थिति
- infrastructure Boundary: service separation होने पर atomicity की guarantee नहीं दी जा सकती
लोगों के बीच बनने वाले Boundary
- organizational Boundary: Conway's Law — संगठन की संरचना सिस्टम की संरचना तय करती है। टीम बदलने पर code और organization की Boundaries असंगत हो जाती हैं
- communication Boundary: telephone game की तरह requirements आगे बढ़ते-बढ़ते intent बदल जाता है, tacit knowledge तो पहुँचती ही नहीं
- user-developer Boundary: developer ने सुरक्षा के लिए जो Boundary बनाई, वही user को झुंझलाने वाली बाधा लग सकती है
Boundary को कैसे संभालें
- छिपी हुई Boundaries को पहचानें: जैसे दो services का एक ही DB table share करना, ऐसे coupling पर ध्यान दें जो code में दिखती नहीं
- patterns ही जवाब नहीं हैं: patterns सिर्फ “कुछ खास परिस्थितियों में असरदार समाधान” हैं, इन्हें अंधाधुंध लागू न करें
- Boundary के सामने पूछे जाने वाले तीन सवाल:
- इस Boundary को पार करके क्या जा रहा है?
- अगर यह Boundary टूट जाए तो क्या होगा?
- इस Boundary को manage कौन करता है?
- Boundary न खींचना भी एक विकल्प है: monolith बनाए रखना, जल्दबाज़ी में separation से बचना आदि
- Boundary विकसित होती है: अलग किया, फिर जोड़ा; जोड़ा, फिर दोबारा बाँटा — इसलिए सोच-समझकर और नियमित रूप से पुनरावलोकन ज़रूरी है
अभी कोई टिप्पणी नहीं है.