मी कोडिंग करणे का थांबवले आणि डिझाइनिंग का सुरू केले
मला वाटायचे की सॉफ्टवेअर डेव्हलपमेंट म्हणजे फक्त फीचर्स लिहिणे होय. मला वाटायचे की माझे काम एंटिटीज (entities) तयार करणे, कंट्रोलर्स (controllers) बनवणे आणि डेटाबेस जोडणे हे आहे.
एका अलीकडील प्रोजेक्टमुळे माझा दृष्टिकोन बदलला. मला समजले की कोडिंग हा केवळ उपायाचा एक भाग आहे. तुम्ही कोडची एक ओळही लिहिण्यापूर्वी खरे काम पूर्ण झाले पाहिजे.
तुम्हाला आर्किटेक्चरवर (architecture) निर्णय घ्यावा लागतो. ते का योग्य आहे, त्याचा खर्च किती येईल आणि ते कोणत्या जोखमींवर उपाय करते, हे तुम्हाला विचारावे लागेल.
माझे मुख्य धडे खालीलप्रमाणे आहेत:
• आर्किटेक्चर हे प्रॉडक्टच्या टप्प्याशी सुसंगत असावे. लगेचच microservices, Kubernetes आणि जटिल event queues वापरणे मोहक वाटते. आमच्या प्रोजेक्टसाठी, आम्ही एका सिंगल प्रोसेसमध्ये लेअर्ड आर्किटेक्चर (layered architecture) निवडले. यामुळे आम्हाला डिस्ट्रिब्युटेड सिस्टमच्या (distributed system) डोकेदुखीशिवाय जबाबदाऱ्या वेगळ्या करण्यास मदत झाली. सुरुवात करताना साधेपणा अनेकदा अधिक चांगला असतो.
• काही निर्णय आता स्वस्त असतात पण नंतर महाग पडतात. आम्ही पहिल्या दिवसापासून आमच्या डेटा मॉडेलमध्ये TenantId जोडला. जरी आमच्याकडे फक्त एकच क्लायंट होता, तरीही यामुळे भविष्यात SaaS मॉडेलकडे वळणे सोपे झाले. जर तुम्ही multi-tenancy जोडण्यासाठी खूप वेळ लावला, तर मायग्रेशन (migration) एक кошळ बनू शकते.
• डिझाइन भविष्यातील अडथळे टाळते. प्रोग्रामिंग ही तात्काळ समस्या सोडवते. डिझाइनिंग भविष्यातील संधी बंद न करता समस्या सोडवते. वेगवेगळ्या इन्फ्रास्ट्रक्चरवर (infrastructure) सहजपणे स्थलांतर करण्यासाठी आम्ही सुरुवातीपासूनच कंटेनर्सचा (containers) वापर केला. प्रोव्हायडर्स बदलणे सोपे करण्यासाठी आम्ही इंटरफेसचा (interfaces) वापर केला.
• व्यवसायातील बदल तांत्रिक बदल घडवून आणतात. व्यवसाय वाढल्यामुळे सिस्टम microservices कडे वळते. एक सिंगल क्लिनिक ॲप शेकडो क्लिनिकसाठी SaaS प्लॅटफॉर्म बनते. या बदलामुळे तुम्ही बिलिंग, सबस्क्रिप्शन आणि स्केलिंग (scaling) कसे हाताळता यात बदल होतो.
• विश्वासार्हतेसाठी स्मार्ट पॅटर्नची आवश्यकता असते. आम्ही synchronous calls कडून event-driven architecture कडे वळलो. मेडिकल सिस्टममध्ये, एखादी संथ नोटिफिकेशन सर्व्हिस अपॉइंटमेंट बुकिंगमध्ये अडथळा आणू नये. मेसेज ब्रोकर (message broker) फेल झाला तरी डेटा सुरक्षित राहील याची खात्री करण्यासाठी आम्ही Outbox पॅटर्नचा वापर केला.
• पॅटर्न हे डोमेनला (domain) सुसंगत असावेत. पॅटर्नचा आंधळेपणाने वापर करू नका. मेडिकल डायग्नोसिससाठी स्ट्रॉन्ग कन्सिस्टन्सी (strong consistency) आवश्यक असते. रुग्णाच्या सुरक्षिततेसाठी तुम्ही 'eventual consistency' वर अवलंबून राहू शकत नाही. जर कॅश (cache) वापरल्यामुळे तुमचा ऑडिट ट्रेल (audit trail) खंडित होत असेल, तर संवेदनशील क्लिनिकल डेटासाठी कॅश वापरू नका.
• DevOps हा नंतरचा विचार नसून सुरुवातीचा भाग आहे. डिप्लॉयमेंट (deployment), हेल्थ चेक आणि पाइपलाइन्स (pipelines) हे सुरुवातीच्या डिझाइनचाच भाग आहेत. तुम्हाला खर्चाचा अंदाज घ्यावा लागेल आणि तुमच्या गरजा पूर्ण करणारे घटक निवडणे आवश्यक आहे.
प्रोग्रामर आणि डिझायनर यांच्यातील फरक हा "का" या प्रश्नात आहे.
प्रोग्रामर विचारतो: "हे मी कसे कार्यान्वित करू?" डिझायनर विचारतो: "या विशिष्ट समस्येसाठी हाच योग्य उपाय का आहे?"