ہیلو ساتھیوں.
آج ہم آپ کے لیے Tugberk Ugurlu کے ایک مضمون کا ترجمہ پیش کرتے ہیں، جس نے نسبتاً کم حجم میں جدید سافٹ ویئر سسٹمز کو ڈیزائن کرنے کے اصولوں کا خاکہ پیش کرنے کا بیڑا اٹھایا۔ خلاصہ یہ ہے کہ مصنف اپنے بارے میں کیا کہتا ہے:
چونکہ 2019 تک آرکیٹیکچرل پیٹرن + ڈیزائن پیٹرن جیسے زبردست موضوع کا احاطہ کسی ہیبرو مضمون میں کرنا بالکل ناممکن ہے، اس لیے ہم نہ صرف خود مسٹر اُروگلو کا متن بلکہ متعدد لنکس بھی تجویز کرتے ہیں جو انھوں نے مہربانی سے اس میں شامل کیے ہیں۔ اگر آپ کو یہ پسند ہے، تو ہم تقسیم شدہ نظاموں کے ڈیزائن کے بارے میں ایک انتہائی خصوصی متن شائع کریں گے۔
سنیپ شاٹ Unsplash سے
اگر آپ کو شروع سے سافٹ ویئر سسٹم کو ڈیزائن کرنے جیسے چیلنجوں کا سامنا نہیں کرنا پڑا ہے، تو اس طرح کا کام شروع کرتے وقت، بعض اوقات یہ بھی واضح نہیں ہوتا کہ کہاں سے شروع کرنا ہے۔ میرا ماننا ہے کہ آپ کو پہلے حدیں کھینچنے کی ضرورت ہے تاکہ آپ کو کم و بیش اعتماد کے ساتھ اندازہ ہو کہ آپ بالکل کیا ڈیزائن کرنے جا رہے ہیں، اور پھر اپنی آستینیں لپیٹیں اور ان حدود میں کام کریں۔ ایک نقطہ آغاز کے طور پر، آپ کوئی پروڈکٹ یا سروس لے سکتے ہیں (مثالی طور پر وہ جو آپ کو واقعی پسند ہے) اور اسے لاگو کرنے کا طریقہ معلوم کر سکتے ہیں۔ آپ حیران ہوں گے کہ یہ پروڈکٹ کتنی سادہ نظر آتی ہے، اور اس میں اصل میں کتنی پیچیدگی ہے۔ بھولنا مت: ، اور یہ ٹھیک ہے۔
میرے خیال میں سسٹم کو ڈیزائن کرنا شروع کرنے والے کسی کو بھی میں جو بہترین مشورہ دے سکتا ہوں وہ یہ ہے: کوئی مفروضہ مت بنائیں! شروع سے ہی، آپ کو اس نظام کے بارے میں معلوم حقائق اور اس سے وابستہ توقعات کی وضاحت کرنے کی ضرورت ہے۔ اپنے ڈیزائن کے ساتھ شروع کرنے میں مدد کے لیے پوچھنے کے لیے یہاں کچھ اچھے سوالات ہیں:
- کیا مسئلہ ہے جسے ہم حل کرنے کی کوشش کر رہے ہیں؟
- صارفین کی سب سے زیادہ تعداد کتنی ہے جو ہمارے سسٹم کے ساتھ تعامل کریں گے؟
- ہم ڈیٹا لکھنے اور پڑھنے کے کون سے نمونے استعمال کریں گے؟
- متوقع ناکامی کے معاملات کیا ہیں، ہم ان کو کیسے سنبھالیں گے؟
- سسٹم کی مستقل مزاجی اور دستیابی کی کیا توقعات ہیں؟
- کیا آپ کو کام کرتے وقت بیرونی تصدیق اور ضابطے سے متعلق کسی بھی تقاضے کو مدنظر رکھنا ہوگا؟
- ہم کس قسم کے حساس ڈیٹا کو ذخیرہ کرنے جا رہے ہیں؟
یہ صرف چند سوالات ہیں جو میرے اور ان ٹیموں دونوں کے لیے کارآمد رہے ہیں جن میں میں نے پیشہ ورانہ سرگرمیوں کے سالوں میں حصہ لیا ہے۔ اگر آپ کو ان سوالوں کے جوابات معلوم ہیں (اور کوئی دوسرا جو اس سیاق و سباق سے متعلق ہے جس میں آپ کو کام کرنا ہے)، تو آپ آہستہ آہستہ مسئلے کی تکنیکی تفصیلات کو تلاش کر سکتے ہیں۔
ابتدائی سطح طے کریں۔
یہاں "بیس لائن" سے میرا کیا مطلب ہے؟ درحقیقت، ہمارے دور میں، سافٹ ویئر انڈسٹری میں زیادہ تر مسائل کو موجودہ طریقوں اور ٹیکنالوجیز کا استعمال کرتے ہوئے "حل" کیا جا سکتا ہے۔ اس کے مطابق، اس زمین کی تزئین پر تشریف لے کر، آپ کو ان مسائل کا سامنا کرنے پر ایک خاص آغاز ملتا ہے جنہیں آپ سے پہلے کسی اور کو حل کرنا تھا۔ یہ نہ بھولیں کہ پروگرام کاروباری اور صارف کے مسائل کو حل کرنے کے لیے لکھے جاتے ہیں، اس لیے ہم اس مسئلے کو انتہائی سیدھے اور سادہ (صارف کے نقطہ نظر سے) حل کرنے کی کوشش کرتے ہیں۔ یہ یاد رکھنا کیوں ضروری ہے؟ ہوسکتا ہے کہ آپ اپنے کوآرڈینیٹ سسٹم میں تمام مسائل کے منفرد حل تلاش کرنا پسند کریں، کیونکہ آپ سوچتے ہیں، "اگر میں ہر جگہ پیٹرن کی پیروی کرتا ہوں تو میں کس قسم کا پروگرامر ہوں"؟ حقیقت میں، یہاں کا فن فیصلہ کر رہا ہے کہ کہاں اور کیا کرنا ہے۔. یقیناً، ہم میں سے ہر ایک کو وقتاً فوقتاً منفرد مسائل سے نمٹنا پڑتا ہے، جن میں سے ہر ایک حقیقی چیلنج ہے۔ تاہم، اگر ہماری ابتدائی سطح کو واضح طور پر بیان کیا گیا ہے، تو ہم جانتے ہیں کہ اپنی توانائی کس چیز پر خرچ کرنی ہے: ہمارے سامنے رکھے ہوئے مسئلے کو حل کرنے کے لیے تیار شدہ اختیارات کی تلاش، یا اس کا مزید مطالعہ کرنا اور گہری سمجھ حاصل کرنا۔
میرا خیال ہے کہ میں آپ کو قائل کرنے میں کامیاب رہا کہ اگر کوئی ماہر اعتماد کے ساتھ سمجھتا ہے کہ کچھ حیرت انگیز سافٹ ویئر سسٹمز کا آرکیٹیکچرل جزو کیا ہے، تو یہ علم ایک معمار کے فن میں مہارت حاصل کرنے اور اس شعبے میں ٹھوس بنیاد تیار کرنے کے لیے ناگزیر ہوگا۔
ٹھیک ہے، تو کہاں سے شروع کرنا ہے؟ یو GitHub پر ایک ذخیرہ ہے جسے کہا جاتا ہے۔ جس سے آپ بڑے پیمانے پر سسٹمز ڈیزائن کرنے کے ساتھ ساتھ اس موضوع پر انٹرویوز کی تیاری سیکھ سکتے ہیں۔ ذخیرہ میں مثالوں کے ساتھ ایک سیکشن ہے۔ ، جہاں، خاص طور پر، اس پر غور کیا جاتا ہے کہ وہ اپنے سسٹم کے ڈیزائن تک کیسے پہنچتے ہیں۔ جیسے ٹویٹر، اوبر، وغیرہ۔
تاہم، اس مواد کی طرف بڑھنے سے پہلے، آئیے ان اہم ترین تعمیراتی چیلنجوں پر گہری نظر ڈالتے ہیں جن کا ہمیں عملی طور پر سامنا ہے۔ یہ اس لیے ضروری ہے کہ آپ کو ایک ضدی اور کثیر جہتی مسئلے کے بہت سے پہلوؤں کی وضاحت کرنی ہوگی، اور پھر اسے کسی مخصوص نظام میں نافذ ضابطوں کے دائرہ کار میں حل کرنا ہوگا۔ فیس بک کے ایک سابق ملازم نے لکھا جہاں اس نے سینکڑوں درخواست دہندگان کی اسکریننگ کا اپنا تجربہ شیئر کیا۔ اگرچہ ویڈیو بڑے سسٹم ڈیزائن اور کامیابی کے ان معیارات پر بہت زیادہ توجہ مرکوز کرتی ہے جو ایسی پوزیشن کے لیے امیدوار کی تلاش میں اہم ہوتے ہیں، پھر بھی یہ ایک جامع وسیلہ کے طور پر کام کرے گا کہ سسٹمز کو ڈیزائن کرتے وقت کون سی چیزیں سب سے اہم ہیں۔ میں بھی تجویز کرتا ہوں۔ یہ ویڈیو.
ڈیٹا کو ذخیرہ کرنے اور بازیافت کرنے کے بارے میں علم حاصل کریں۔
عام طور پر، آپ کے اس فیصلے کے بارے میں کہ آپ اپنے ڈیٹا کو طویل مدت تک کیسے ذخیرہ اور بازیافت کرتے ہیں سسٹم کی کارکردگی پر ایک اہم اثر ڈالتا ہے۔ لہذا، آپ کو پہلے اپنے سسٹم کی متوقع تحریر اور پڑھنے کی خصوصیات کو سمجھنا چاہیے۔ پھر آپ کو ان اشاریوں کا جائزہ لینے اور کئے گئے جائزوں کی بنیاد پر انتخاب کرنے کے قابل ہونے کی ضرورت ہے۔ تاہم، آپ اس کام سے مؤثر طریقے سے تبھی نمٹ سکتے ہیں جب آپ موجودہ ڈیٹا اسٹوریج پیٹرن کو سمجھتے ہیں۔ اصولی طور پر اس کا مطلب ٹھوس علم سے متعلق ہے۔ .
ڈیٹا بیس کو ڈیٹا ڈھانچے کے طور پر سوچا جا سکتا ہے جو انتہائی قابل توسیع اور پائیدار ہیں۔ لہذا، ڈیٹا سٹرکچر کا علم آپ کے لیے کسی خاص ڈیٹا بیس کا انتخاب کرتے وقت بہت مفید ہونا چاہیے۔ مثال کے طور پر، ایک ڈیٹا سٹرکچر سرور ہے جو مختلف قسم کی اقدار کو سپورٹ کرتا ہے۔ یہ آپ کو ڈیٹا ڈھانچے جیسے فہرستوں اور سیٹوں کے ساتھ کام کرنے اور معروف الگورتھم کا استعمال کرتے ہوئے ڈیٹا پڑھنے کی اجازت دیتا ہے، مثال کے طور پر، ، اس طرح کے کام کو پائیدار اور انتہائی قابل رسائی انداز میں منظم کرنا۔
سنیپ شاٹ Unsplash سے
ایک بار جب آپ کو ڈیٹا ذخیرہ کرنے کے مختلف نمونوں کے بارے میں کافی سمجھ آ جائے تو ڈیٹا کی مستقل مزاجی اور دستیابی کا مطالعہ کرنے کے لیے آگے بڑھیں۔ سب سے پہلے، آپ کو سمجھنے کی ضرورت ہے کم از کم عام اصطلاحات میں، اور پھر قائم شدہ نمونوں کو قریب سے دیکھ کر اس علم کو پالش کریں۔ и . اس طرح، آپ فیلڈ کے بارے میں سمجھ پیدا کریں گے اور یہ سمجھیں گے کہ ڈیٹا کو پڑھنا اور لکھنا دراصل دو بالکل مختلف مسائل ہیں، جن میں سے ہر ایک کے اپنے منفرد چیلنجز ہیں۔ کچھ مستقل مزاجی اور دستیابی کے نمونوں سے لیس، آپ اپنی ایپلی کیشنز میں ڈیٹا کے بہاؤ کو یقینی بناتے ہوئے سسٹم کی کارکردگی میں نمایاں اضافہ کر سکتے ہیں۔
آخر میں، ڈیٹا سٹوریج کے مسائل کے بارے میں گفتگو کو ختم کرتے ہوئے، ہمیں کیشنگ کا بھی ذکر کرنا چاہیے۔ کیا اسے کلائنٹ اور سرور پر بیک وقت چلنا چاہئے؟ آپ کے کیش میں کون سا ڈیٹا ہوگا؟ اور کیوں؟ آپ کیشے کی غلط کاری کو کیسے منظم کرتے ہیں؟ کیا یہ کچھ وقفوں پر باقاعدگی سے کیا جائے گا؟ اگر ہاں تو کتنی بار؟ میں ان عنوانات کا مطالعہ شروع کرنے کی تجویز کرتا ہوں۔ مذکورہ بالا نظام ڈیزائن پرائمر۔
مواصلاتی پیٹرن
نظام مختلف اجزاء پر مشتمل ہے؛ یہ ایک ہی فزیکل نوڈ کے اندر چلنے والے مختلف عمل ہوسکتے ہیں، یا آپ کے نیٹ ورک کے مختلف حصوں پر چلنے والی مختلف مشینیں ہوسکتی ہیں۔ آپ کے نیٹ ورک کے اندر ان میں سے کچھ وسائل نجی ہو سکتے ہیں، لیکن دیگر عوامی ہونے چاہئیں اور باہر سے ان تک رسائی حاصل کرنے والے صارفین کے لیے کھلے ہونے چاہئیں۔
ان وسائل کے ایک دوسرے کے ساتھ رابطے کے ساتھ ساتھ پورے نظام اور بیرونی دنیا کے درمیان معلومات کے تبادلے کو یقینی بنانا ضروری ہے۔ سسٹم ڈیزائن کے تناظر میں، یہاں ایک بار پھر ہمیں نئے اور منفرد چیلنجز کا سامنا ہے۔ آئیے دیکھتے ہیں کہ وہ کس طرح مفید ہو سکتے ہیں۔ ، اور کیا پی.
سنیپ شاٹ Unsplash سے
بیرونی دنیا کے ساتھ مواصلات کو منظم کرتے وقت، یہ ہمیشہ بہت اہم ہے ، جس کی فراہمی کو بھی سنجیدگی سے لینے اور فعال طور پر پیروی کرنے کی ضرورت ہے۔
کنکشن کی تقسیم
مجھے یقین نہیں ہے کہ اس موضوع کو الگ سیکشن میں ڈالنا ہر کسی کے لیے جائز معلوم ہوگا۔ بہر حال، میں اس تصور کو یہاں تفصیل سے پیش کروں گا، اور مجھے یقین ہے کہ اس سیکشن میں موجود مواد کو "کنکشن ڈسٹری بیوشن" کی اصطلاح سے بالکل درست طریقے سے بیان کیا گیا ہے۔
سسٹم بہت سے اجزاء کو صحیح طریقے سے جوڑنے سے تشکیل پاتے ہیں، اور ان کا ایک دوسرے کے ساتھ مواصلات اکثر قائم شدہ پروٹوکولز کی بنیاد پر ترتیب دیا جاتا ہے، مثال کے طور پر، TCP اور UDP۔ تاہم، یہ پروٹوکول اکثر جدید نظاموں کی تمام ضروریات کو پورا کرنے کے لیے ناکافی ہوتے ہیں، جو اکثر زیادہ بوجھ کے تحت چلتے ہیں اور صارف کی ضروریات پر بھی بہت زیادہ انحصار کرتے ہیں۔ سسٹم پر اس طرح کے زیادہ بوجھ سے نمٹنے کے لیے کنکشن تقسیم کرنے کے طریقے تلاش کرنا اکثر ضروری ہوتا ہے۔
یہ تقسیم معروف پر مبنی ہے۔ (DNS)۔ اس طرح کا نظام ڈومین نام کی تبدیلیوں کی اجازت دیتا ہے جیسا کہ وزنی راؤنڈ رابن اور تاخیر پر مبنی طریقوں سے بوجھ کو تقسیم کرنے میں مدد ملتی ہے۔
بنیادی طور پر اہم ہے، اور تقریباً ہر بڑا انٹرنیٹ سسٹم جس کے ساتھ ہم آج ڈیل کرتے ہیں ایک یا زیادہ لوڈ بیلنسرز کے پیچھے واقع ہے۔ لوڈ بیلنسرز متعدد دستیاب مثالوں میں کلائنٹ کی درخواستوں کو تقسیم کرنے میں مدد کرتے ہیں۔ لوڈ بیلنسرز ہارڈ ویئر اور سافٹ ویئر دونوں میں آتے ہیں، تاہم، عملی طور پر، آپ کو اکثر سافٹ ویئر والوں سے نمٹنا پڑتا ہے، مثال کے طور پر и . تصوراتی طور پر بھی لوڈ بیلنسرز سے بہت ملتا جلتا ہے، حالانکہ پہلے اور دوسرے کے درمیان ایک حد ہوتی ہے۔ . آپ کی ضروریات پر مبنی نظام کو ڈیزائن کرتے وقت ان اختلافات کو مدنظر رکھنا چاہیے۔
کے بارے میں بھی جاننا چاہیے۔ (CDN)۔ CDN پراکسی سرورز کا ایک عالمی تقسیم شدہ نیٹ ورک ہے جو نوڈس سے معلومات فراہم کرتا ہے جو جغرافیائی طور پر کسی مخصوص صارف کے قریب واقع ہیں۔ اگر آپ JavaScript، CSS اور HTML میں لکھی گئی جامد فائلوں کے ساتھ کام کرتے ہیں تو CDN استعمال کرنا بہتر ہے۔ اس کے علاوہ، کلاؤڈ سروسز جو ٹریفک مینیجرز فراہم کرتی ہیں آج کل عام ہیں، مثال کے طور پر، ، متحرک مواد کے ساتھ کام کرتے وقت آپ کو عالمی تقسیم اور کم تاخیر فراہم کرتا ہے۔ تاہم، ایسی خدمات عام طور پر ایسے معاملات میں کارآمد ہوتی ہیں جہاں آپ کو اسٹیٹ لیس ویب سروسز کے ساتھ کام کرنا پڑتا ہے۔
آئیے کاروباری منطق کے بارے میں بات کرتے ہیں۔ کاروباری منطق، کام کے بہاؤ اور اجزاء کی تشکیل
لہذا، ہم نظام کے مختلف بنیادی ڈھانچے کے پہلوؤں پر بات کرنے میں کامیاب ہوئے۔ زیادہ تر امکان ہے کہ، صارف آپ کے سسٹم کے ان تمام عناصر کے بارے میں نہیں سوچتا اور واضح طور پر، ان کی بالکل بھی پرواہ نہیں کرتا ہے۔ صارف اس بات میں دلچسپی رکھتا ہے کہ آپ کے سسٹم کے ساتھ بات چیت کرنا کیسا ہے، ایسا کرنے سے کیا حاصل کیا جا سکتا ہے، اور یہ بھی کہ سسٹم صارف کے احکامات پر کیسے عمل کرتا ہے، صارف کے ڈیٹا کے ساتھ کیا اور کیسے کرتا ہے۔
جیسا کہ اس مضمون کے عنوان سے پتہ چلتا ہے، میں سافٹ ویئر فن تعمیر اور سسٹم ڈیزائن کے بارے میں بات کرنے جا رہا تھا۔ اسی مناسبت سے، میں نے سافٹ ویئر ڈیزائن کے نمونوں کا احاطہ کرنے کا منصوبہ نہیں بنایا جو یہ بیان کرتے ہیں کہ سافٹ ویئر کے اجزاء کیسے بنائے جاتے ہیں۔ تاہم، میں اس کے بارے میں جتنا زیادہ سوچتا ہوں، اتنا ہی مجھے لگتا ہے کہ سافٹ ویئر ڈیزائن پیٹرن اور آرکیٹیکچرل پیٹرن کے درمیان لائن بہت دھندلی ہے، اور دونوں تصورات کا آپس میں گہرا تعلق ہے۔ آئیے مثال کے طور پر لیتے ہیں۔ (ایونٹ سورسنگ)۔ ایک بار جب آپ اس آرکیٹیکچرل پیٹرن کو اپنا لیتے ہیں، تو یہ آپ کے سسٹم کے تقریباً ہر پہلو کو متاثر کرے گا: ڈیٹا کا طویل مدتی ذخیرہ، آپ کے سسٹم میں اختیار کردہ مستقل مزاجی کی سطح، اس میں موجود اجزاء کی شکل، وغیرہ۔ لہذا، میں نے کچھ تعمیراتی نمونوں کا ذکر کرنے کا فیصلہ کیا جو براہ راست کاروباری منطق سے متعلق ہیں۔ اگرچہ اس مضمون کو خود کو ایک سادہ فہرست تک محدود رکھنا پڑے گا، میں آپ کو اس سے واقف ہونے اور ان نمونوں سے وابستہ خیالات کے بارے میں سوچنے کی ترغیب دیتا ہوں۔ آپ یہ ہیں:
- تصور کا۔ ، خاص طور پر، ,
باہمی تعاون کے طریقے
اس بات کا بہت امکان نہیں ہے کہ آپ اپنے آپ کو کسی پروجیکٹ میں شریک کے طور پر پائیں گے جو سسٹم ڈیزائن کے عمل کے لیے مکمل طور پر ذمہ دار ہے۔ اس کے برعکس، آپ کو اپنے کام کے اندر اور باہر کام کرنے والے ساتھیوں کے ساتھ بات چیت کرنا پڑے گی۔ اس صورت میں، آپ کو ساتھیوں کے ساتھ منتخب ٹیکنالوجی کے حل کا جائزہ لینے، کاروباری ضروریات کی شناخت کرنے اور کاموں کو متوازی کرنے کے بہترین طریقے کو سمجھنے کی ضرورت پڑ سکتی ہے۔
سنیپ شاٹ Unsplash سے
پہلا قدم یہ ہے کہ آپ جس کاروباری مقصد کو حاصل کرنے کی کوشش کر رہے ہیں وہ کیا ہے اور آپ کو کن متحرک حصوں سے نمٹنا پڑے گا اس کے بارے میں درست اور مشترکہ سمجھ پیدا کرنا ہے۔ گروپ ماڈلنگ کی تکنیکیں، خاص طور پر (واقعہ طوفان) اس عمل کو نمایاں طور پر تیز کرنے اور کامیابی کے امکانات کو بڑھانے میں مدد کرتا ہے۔ یہ کام آپ کے خاکہ سے پہلے یا بعد میں کیا جا سکتا ہے۔ ، اور پھر مصنوعات کی پختگی کے ساتھ اسے گہرا کریں۔ مستقل مزاجی کی سطح کی بنیاد پر جو یہاں حاصل کی جائے گی، آپ بھی تشکیل دے سکتے ہیں۔ اس محدود سیاق و سباق کے لیے جس میں آپ کام کرتے ہیں۔ جب آپ کو اپنے سسٹم کے فن تعمیر کے بارے میں بات کرنے کی ضرورت ہو، تو آپ کو یہ مفید معلوم ہو سکتا ہے۔ ، مجوزہ خاص طور پر جب آپ کو یہ سمجھنے کی ضرورت ہو کہ آپ کو مسئلہ کی تفصیلات میں کتنا جانا پڑے گا، ان چیزوں کا تصور کرتے ہوئے جن سے آپ بات چیت کرنا چاہتے ہیں۔
اس موضوع پر شاید ایک اور پختہ ٹیکنالوجی ہے جو ڈومین ڈرائیون ڈیزائن سے کم مفید نہیں ہے۔ تاہم، ہم کسی نہ کسی طرح موضوع کے علاقے کو سمجھنے کے لئے واپس آتے ہیں، لہذا میدان میں علم اور تجربہ آپ کے لئے مفید ہونا چاہئے.
ماخذ: www.habr.com