- C4 मॉडल सॉफ्टवेयर आर्किटेक्चर डायग्राम बनाने के लिए developer-friendly approach है, जो जटिल संरचना को चरणबद्ध तरीके से देखने में मदद करता है
- abstraction, software systems → containers → components → code क्रम में नीचे जाती है और आर्किटेक्चर को hierarchical तरीके से संभालती है
- डायग्राम भी system context → container → component → code संरचना का अनुसरण करते हुए बनाए जाते हैं
- ज़रूरत के अनुसार system landscape, dynamic, deployment डायग्राम पूरे ढांचे और execution·deployment दृष्टिकोण को पूरक करते हैं
- यह notation independent, tooling independent तरीका है, इसलिए इसे मौजूदा environment के अनुसार लागू किया जा सकता है
C4 मॉडल की संरचना
- C4 मॉडल सॉफ्टवेयर आर्किटेक्चर को विज़ुअलाइज़ करने के लिए एक मॉडल है, और इसे Simon Brown ने बनाया है
- इसका मुख्य बिंदु hierarchical abstraction और hierarchical diagram का साथ में उपयोग करना है
डायग्राम और स्वतंत्रता
- मूल डायग्राम इस तरह बनाए गए हैं कि आर्किटेक्चर को अलग-अलग गहराई पर देखा जा सके
- सहायक डायग्राम उन दृष्टिकोणों को पूरा करते हैं जो केवल मूल hierarchy से पर्याप्त रूप से नहीं दिखते
- यह मॉडल notation independent और tooling independent है, इसलिए यह किसी खास notation या tool के चयन को मजबूर नहीं करता
- संबंधित सामग्री के रूप में जुलाई 2019 में “Agile on the Beach 2019” में रिकॉर्ड किया गया Visualising software architecture with the C4 model वीडियो और The C4 model सामग्री उपलब्ध है
1 टिप्पणियां
Hacker News की राय
मुझे लगता है कि architecture diagrams की सबसे बड़ी समस्या यह है कि वे codebase से mismatch हो जाते हैं
ऐसे diagrams auto-generate होने चाहिए। वरना team के पास यह जानने का कोई तरीका नहीं होता कि जो diagram अभी दिख रहा है, वह system की latest state को सही-सही दिखा रहा है या नहीं
Diagrams एक खास viewpoint दिखाते हैं; कुछ features को highlight करते हैं और कुछ को छोड़ देते हैं। एक ही चीज़ के लिए अलग-अलग aspects या scenarios समझाने वाले कई diagrams हो सकते हैं। आखिरकार diagrams को भी text documents की तरह code और application architecture के साथ maintain करना पड़ता है, और इसे change management का नियमित काम बनाना ही पड़ता है
कई projects में code को उस mental model की तरह organize नहीं किया जाता, और लगभग कोई भी language इसे हल करने का तरीका नहीं देती। code में comments से mark करना भी diagrams, comments और docs को up to date रखने जैसी ही समस्या रखता है
वे current state नहीं, बल्कि target state दिखाते हैं। code को diagram follow करना चाहिए, उल्टा नहीं। code से diagram generate करना तभी meaningful होता है जब बिना documentation वाले project में नए joiner की मदद करनी हो; तब भी एक बार generate करके noise हटाकर refine किया जाता है और फिर उसे reference document की तरह use किया जाता है
high-level diagrams जल्दी बनाए और discard किए जा सकने चाहिए, और क्या दिखाना है जितना महत्वपूर्ण है, उतना ही महत्वपूर्ण यह भी है कि क्या छोड़ना है
मुझे C4 पसंद है। पहले मैं “User -{do their job}-> System-of-Record” जैसे context diagrams को बेकार मानता था, लेकिन अब वजह समझ में आती है
हम एक complex system का नया design extended teams के साथ C4 में कर रहे हैं। इस बार top-level picture बनाते समय ध्यान आया कि web UI के अलावा एक mobile app भी है जो आधा disconnected हो सकता है, इसलिए offline होने पर या backend slow होने पर, अगर कुछ results अभी मौजूद नहीं हैं, तो कुछ operations को gracefully degrade करना होगा। अगले layer में यह work queue तक गया, और फिर वापस UX तक, जिससे हम साफ कह सके कि किन requests के complete होने में अनिश्चित रूप से लंबा समय लग सकता है। शायद हम कभी न कभी वहां पहुंच ही जाते, लेकिन analysis ने इस issue को सीधे सामने ला दिया। यह सब इसलिए हुआ क्योंकि हमें “Remote-User --{Mobile Stuff}--> Backend” वाला picture बनाना पड़ा। tool कोई भी हो, फर्क नहीं पड़ता; मैं, उदाहरण के लिए, draw.io में layers के लिए अलग-अलग tabs इस्तेमाल करता हूं। और detail आने पर lower layers को अलग files में अलग कर दूंगा
यह तर्क भी समझ में आता है कि diagrams के लिए formalized system की जरूरत नहीं है, लेकिन मुझे C4 काफी lightweight लगता है। मैं code level तक नहीं उतरता
फिर भी C4 diagrams output करने वाला structurizr मेरी productivity काफी बढ़ा गया। एक ही model से अलग-अलग detail levels के views generate करने का तरीका mermaid या plantuml वगैरह की तुलना में बढ़िया है, जहां हर diagram को independently उन्हीं components को बार-बार define और redefine करना पड़ता है। branch बनाकर model modify करना और ideas present करना—यह flow मेरे लिए बहुत अच्छी तरह fit हुआ
C4 में strict रूप से न आने वाले concepts को draw करने का तरीका नहीं था। जैसे मैं दो components को एक box में रखकर यह दिखाना चाहता था कि वे अभी एक service के रूप में deployed हैं, लेकिन यह संभव नहीं था। इसका मतलब यह नहीं कि वह absolutely अच्छा design है, लेकिन team को समझने में मदद मिलती। architecture को formally describe करने का idea अच्छा है, लेकिन diagram output की customization की कमी बहुत मुश्किल लगी
आप architecture describe करते हैं और structurizr diagram render करता है
किया जा सकता है, लेकिन काफी झंझट है, और boxes के बीच arrows की descriptions लंबी होने लगें तो auto-layout जल्दी टूट जाता है
मैं software architecture को implementation को दिशा देने वाले design decisions के समूह के रूप में देखता हूँ
मेरे अनुभव में ज़्यादातर software architects, software engineers को guidelines और structure देते हैं। लेकिन C4 की व्याख्या में “existing code का map कई detail levels पर बनाता है” वाली बात अलग लगती है। समझ नहीं आता कि code diagrams को software architecture क्यों कहा जाए। वह तो सचमुच code level है; फिर वह architecture कैसे हुआ? यह कुछ ऐसा है जैसे घर के blueprint में plug के अंदर का circuit diagram डालना। अगर “automation tools इस्तेमाल करने चाहिए” तो क्या मतलब existing codebase को function-by-function document करना है? समझ नहीं आता कि software को design और plan करने में यह कैसे उपयोगी है। Existing software structure समझाने वाला map अच्छा हो सकता है, लेकिन design patterns पर बात करते समय हम singleton implementation का function-wise map नहीं देते। बस इतना कहना काफी है कि singleton या repository pattern चाहिए। Software design अपने-आप में निश्चित रूप से मौजूद है और यह तरीका भी design के लिए वाजिब लगता है, लेकिन मेरे अनुभव में software design, implementation और architecture एक जैसे नहीं हैं और इन्हें वही लोग भी नहीं करते। यह system design के ज़्यादा करीब लगता है, और software architect की भूमिका शायद यह सलाह देने की होगी कि वह system design अच्छे architecture principles के अनुरूप रहे। शायद मैं बहुत ज़्यादा बारीकी पकड़ रहा हूँ
मेरे हिसाब से software architecture की एक आवश्यक भूमिका developers को इतनी जानकारी देना है कि वे हर बार किसी authority पर फैसला न छोड़कर खुद design decisions ले सकें। हालांकि architecture कहाँ खत्म होता है और development कहाँ शुरू होता है, यह बहुत बदलता रहता है। मुझे लगता है architecture खुद तय करता है कि architecture के नजरिए से क्या महत्वपूर्ण है। अगर architecture यह मानता है कि कोई low-level application detail महत्वपूर्ण है, तो वह भी architecture detail बन जाती है। असल में ज़्यादातर organizations में architecture कम-से-कम components, communication patterns, API, इस्तेमाल की जाने वाली technologies जैसी high-level design चीज़ों को control करता है। कुछ organizations में यह individual classes तक भी चला जाता है। सभी classes नहीं, बल्कि problem domain को model करने वाली classes—खासकर जब वह model कई projects की भाषा के रूप में इस्तेमाल हो या shared artifact के रूप में implement हो। C4 उन organizations के लिए उपयुक्त है जो applications और integration interfaces की list से आगे बढ़कर lower-level structure को भी architecture concern मानती हैं
मूल रूप से system में हर उस level के लिए diagram रखना है जो स्पष्ट रूप से अलग या उपयोगी हो। अगर code-level diagram की ज़रूरत पड़ रही है, तो बहुत संभावना है कि आप कोई complex custom work कर रहे हैं, या फिर ऐसी design को ज़रूरत से ज़्यादा specify कर रहे हैं जिसे implementation detail के रूप में छोड़ा जा सकता था
यह real-world real estate construction में architect, engineer और site supervisor की अलग-अलग भूमिकाओं जैसा है। मैं जानना चाहूँगा कि architecture, design और implementation में अलग-अलग कहाँ रेखा खींचनी चाहिए, और किन concerns को संभालना चाहिए
दिलचस्प है, लेकिन यह कहना मुश्किल है कि यह कुछ खास नया जोड़ता है
high-level diagrams अच्छे हैं, लेकिन उन्हें बनाने के लिए किसी fancy visual model website को पढ़ना ज़रूरी नहीं। Site भी असल में इसे मानती है। Industry में UML, ArchiMate, SysML हैं, लेकिन कई teams ने कहीं ज़्यादा सरल “boxes and lines” diagrams चुने—यह बात बिल्कुल सही है। लेकिन लगता है कि इसने यह ignore कर दिया कि UML class diagrams पूरी तरह fail क्यों हुए। यह मानता है कि उन्हें कोई पसंद नहीं करता, फिर भी model का चौथा C, यानी code, आखिरकार UML class diagram ही है। ऐसी चीज़ों की ज़रूरत नहीं। बस arbitrary diagrams साफ़-साफ़ बनाइए और arrows पर labels लगा दीजिए। पहले तीन diagrams तो इसके अच्छे उदाहरण हैं
नए concepts सोचते या brainstorming करते समय भी tool रास्ते में नहीं आता, इसलिए यह बहुत मददगार है। अभी मैं Freeform इस्तेमाल करता हूँ; यह बहुत simple है लेकिन अच्छे से काम करता है। दो objects select करके cmd-click या right click करें और “add connecting line” दबा दें
कुछ ही महीने पहले मैंने एक और architecture document पूरा किया जिसमें class diagrams, sequence diagrams और use cases पर्याप्त मात्रा में शामिल थे
Boxes में अलग-अलग levels की चीज़ें आसानी से मिल जाती हैं। कुछ abstract होती हैं, कुछ concrete, और कुछ बस arbitrary। इसलिए, उदाहरण के लिए, अगर supply chain जैसा बड़ा architecture piece fit करना हो, तो असल में लगभग सब दोबारा करना पड़ता है। बहुत waste होता है, और पूरी architecture को पर्याप्त स्पष्टता से देखने वाला भी कोई नहीं होता, जिससे और waste और quality issues पैदा होते हैं। अजीब बात है कि कई engineers ज़्यादा formal approach पर defensive प्रतिक्रिया देते हैं; शायद इसलिए कि immediate benefit नहीं दिखता या उन्होंने large-scale architecture से काम नहीं किया, इसलिए समस्या नहीं देख पाते
यह दिखाता है कि software engineering अभी भी एक immature field है
मेरे मामले में 25 साल से ज़्यादा हो गए, फिर भी हम अब भी लगभग “basics” वाली वही चर्चाएँ कर रहे हैं। इसका मतलब यह नहीं कि यह बुरा है, लेकिन progress धीमी है, और इसे सिर्फ किसी खास company, consortium या commercial interests पर नहीं डाला जा सकता
कितनी बार ऐसा हुआ है कि कोई व्यक्ति एक ही विचार में high detail और high complexity से लेकर दूर से दिखने वाली simplicity के बीच लगातार ऊपर-नीचे जाता रहा, और समझना मुश्किल हो गया कि वह कहना क्या चाहता है? जब कोई developer सोचता है, “बस इस board पर boxes और arrows ठीक-ठाक बना दो, मेरे दिमाग में तो समझ आता है इसलिए diagram अच्छा है,” तब भी यही समस्या आती है
Civil engineer न होने पर भी floor plan जैसी चीज़ तुरंत समझ में आ जाती है और उपयोगी लगती है
लेकिन professional software engineer होने के बावजूद ये example diagrams मुझे इतनी मेहनत के लायक उपयोगी या पर्याप्त informative नहीं लगते। Code बहुत multi-dimensional होता है, इसलिए उसे 2D image में approximate करना मुश्किल है और यह अच्छे से काम नहीं करता। संभावना ज़्यादा convention-based architecture code patterns में है। जैसे structured concurrency, और शायद उससे भी higher-level कुछ
Floor plan का context बहुत fixed होता है और scope limited। उदाहरण के लिए, window को समझाने की ज़रूरत नहीं होती। लेकिन software में अक्सर “window” को सच में समझाना पड़ता है। हर “window” या element अलग होता है, इसलिए बस यह कहकर कि यह window है, उसे 20 बार copy नहीं किया जा सकता
अगर C4 मॉडल आपको बहुत मनमाना और ज़रूरत से ज़्यादा specified लगता है, तो मैंने इस साल की शुरुआत में वैकल्पिक practices के बारे में लिखा था: https://www.ilograph.com/blog/posts/concrete-diagramming-mod...
मुझे यह मॉडल पसंद है, और security architecture में UML इस्तेमाल करना पड़ा है। क्योंकि वहाँ top-level context से लेकर code तक consistency ही मुख्य बात होती है
C4 मॉडल की simplicity एक तरह की forcing mechanism है। अगर कोई hidden context या component है, तो वह model में सामने आना चाहिए। अगर इतनी simple चीज़ पर भी resistance है, तो इसे hidden elements हो सकने का संकेत मानता हूँ। बड़े projects में ऐसे elements वाकई आम तौर पर होते हैं। लोगों से इस तरह अपनी सोच स्पष्ट करवाने पर, वे सिर्फ सुझाव देने और आलोचना का अधिकार बचाए रखने के बजाय statements और ideas पर commit करते हैं, जिससे authority distributed हो जाती है। इस पर भी काफी resistance पैदा हो सकता है। हालांकि यह model की समस्या नहीं, बल्कि model के लोगों से मिलने पर होने वाली बात है। consistency पसंद होने की वजह से शायद मैं security design reference के तौर पर ऐसा तरीका इस्तेमाल करूँगा
C4 बहुत दिलचस्प है और software architecture की एक खास समस्या को अच्छी तरह address करता है
यह architecture की निचली layers, यानी मुख्य रूप से hardware और system software, को broad abstraction में रखता है और उसके ऊपर के stack की चीज़ों पर effort focus करवाता है। आज के cloud-based, containerized, scalable approach के साथ यह हैरान करने वाली अच्छी तरह fit बैठता है। इससे जुड़ा ArchiMate भी अच्छा है और काफी overlap है, लेकिन वह infrastructure side में ज्यादा मजबूती से rooted है। पहले मैंने ArchiMate जैसे diagramming approach का इस्तेमाल करके systems और data sources के conflicts कम किए थे, और यह दिखाने में बहुत असरदार पाया था कि जिन चीज़ों को हम खरीदकर जोड़ते हैं वे किसी खास business और user workflow requirements को कैसे support करती हैं। यह बात पूरी तरह सही है कि ये चीज़ें codebase से out of sync हो जाती हैं। लेकिन जब complex systems को analyze करना हो या किसी बड़े group को systems और plans communicate करने हों, तो ये बेहतरीन tools हो सकते हैं। हैरानी की बात है कि कई बार coherent documentation बिल्कुल नहीं होता, और कुछ हफ्ते बैठकर सिर्फ boxes और connecting lines बनाने से भी अटका हुआ, frustrating काम आगे बढ़ सकता है और simple हो सकता है। खासकर तब जब कई teams एक ही area में काम कर रही हों। C4, ArchiMate, UML वगैरह बस constrained diagramming languages हैं, जो उस specific content को capture करती हैं जिसे आप communicate, analyze या record करना चाहते हैं। मुझे नहीं लगता कि ये upfront planning या design tools के रूप में बहुत अच्छी हैं। बड़े UML hype के दौर में बहुत लोगों ने परेशानी झेली। senior architects की organization को code की एक line लिखे जाने से पहले class definitions तक system के हर पहलू को दर्दनाक detail में बिछाना होता था, और “diagram से code generate कर देंगे” जैसी madness ने अनगिनत लोगों को परेशान किया। actual coding शुरू होते ही planning के वे हजारों घंटे आम तौर पर ignore हो जाते थे, और developers अंततः वही करते थे जो वे करना चाहते थे