در این بخش ما قصد داریم در مورد چند نوع محدودیت که بر اساس منبع آنها طبقه بندی شده اند و همچنین تأثیراتی که محدودیت های سیستم بر معماری نرم افزار ما دارند صحبت کنیم.
در نهایت، ما در مورد چند ملاحظه صحبت خواهیم کرد که باید در هنگام برخورد با محدودیت های سیستم به آنها توجه کنیم.
محدودیت های سیستم چیست؟
به طور معمول، هنگامی که الزامات عملکردی و آنچه سیستم ما باید انجام دهد را تعریف می کنیم، آزادی بالایی در مورد نحوه ساختار سیستم خود داریم.به عبارت دیگر، هنگام تعریف معماری نهایی، ما باید تصمیمات زیادی بگیریم زیرا معمولاً راه های زیادی برای دستیابی به ویژگی های کیفی مطلوب و عملکرد مطلوب داریم. به‌ویژه وقتی صحبت از ویژگی‌های کیفیت به میان می‌آید، ما مجاز هستیم و معمولاً انتظار می‌رود که معاوضه‌هایی انجام دهیم.
بنابراین محدودیت سیستم اساساً تصمیمی است که قبلاً یا به طور کامل یا جزئی برای ما گرفته شده بود و درجات آزادی ما را محدود می کرد.
اما این همیشه چیز بدی نیست. به همین دلیل است که گاهی افراد از محدودیت های سیستم به عنوان ستون های معماری نرم افزار ما یاد می کنند.
دلیل آن این است که محدودیت های سیستم نقطه شروع محکمی را برای ما فراهم می کند.
و از آنجایی که معمولاً محدودیت ها غیرقابل مذاکره هستند، ما به نوعی نیاز داریم که بقیه سیستم را حول آن محدودیت ها طراحی کنیم.
انواع محدودیت های سیستم
به طور کلی، سه نوع محدودیت وجود دارد:
- محدودیت های فنی
- محدودیت های تجاری
- محدودیت های قانونی
به عنوان مهندسان نرم افزار، محدودیت های فنی چیزی است که ما هر روز با آن سر و کار داریم، بنابراین برای ما چیز جدیدی نیست.
نمونه هایی از محدودیت های فنی شامل مواردی مانند وابستگی به یک سخت افزار خاص یا سرویس ابری به دلیل یک قرارداد موجود یا دلایل امنیتی است.
مجبور به استفاده از یک زبان برنامه نویسی خاص به دلیل چارچوب های موجودی که در داخل ساخته ایم یا شاید در استخدام مهندسان مشکل داریم، مجبور به استفاده از یک پایگاه داده یا فناوری خاص یا مجبور به پشتیبانی از پلتفرم ها، مرورگرها یا سیستم عامل های خاص به دلیل مجوزها، هزینه پشتیبانی یا شاید به این دلیل که مشتریان ما به طور خاص آن را درخواست می کنند.
مثال : این است که اگر مجبور باشیم از برخی از مرورگرهای قدیمی یا دستگاه های تلفن همراه پایین رده که از پروتکل های ارتباطی خاصی پشتیبانی نمی کنند یا نمی توانند داده های زیادی را مدیریت کنند، پشتیبانی کنیم، باید معماری خود را به طور قابل توجهی برای پشتیبانی از آن پلتفرم ها و API های آنها در نظر بگیریم. ارائه یک تجربه متفاوت و پیشرفته تر برای مرورگرهای جدیدتر یا دستگاه های پیشرفته تر.
حال اجازه دهید در مورد نوع دوم محدودیتی که از تجارت ما ناشی می شود صحبت کنیم.
به طور معمول به عنوان مهندس، ما می خواهیم تصمیمات درست و انتخاب های معماری را از منظر فنی بگیریم، اما همیشه نمی توانیم ارزیابی کنیم که چگونه این تصمیمات با اهداف کسب و کار ما مطابقت دارند.
به همین دلیل، ما اغلب محدودیت‌هایی را دریافت می‌کنیم که از تیم تجاری ما ناشی می‌شود که ما را مجبور می‌کند از نظر معماری و پیاده‌سازی فداکاری کنیم.
به عنوان مثال، اگر محدودیت کسب و کار را به شکل بودجه محدود یا ضرب الاجل دریافت کنیم، انتخاب های بسیار متفاوتی نسبت به زمانی که بودجه نامحدود یا زمان نامحدود داشته باشیم، خواهیم داشت.
در واقع، الگوهای معماری نرم‌افزاری وجود دارد که برای استارت‌آپ‌های کوچکی که باید سریعاً با یک تیم کوچک وارد بازار شوند، مناسب‌تر هستند و الگوهای معماری دیگری وجود دارند که با سازمان‌های بزرگ‌تری که تیم‌های مهندسی زیادی دارند و تیم‌های بسیار بزرگ‌تر دارند، بسیار مناسب‌تر هستند.
علاوه بر محدودیت‌های زمانی و بودجه، می‌توانیم یک محدودیت تجاری نیز دریافت کنیم که به ما می‌گوید از خدمات third party به عنوان بخشی از معماری خود استفاده کنیم. برای مثال، اگر در حال ساخت یک فروشگاه آنلاین هستیم، ممکن است بخواهیم بعد از سرویس حمل و نقل خارج از سازمان استفاده کنیم
مثال دیگر این است که اگر ما در حال ساختن یک پلتفرم سرمایه گذاری هستیم، معمولاً باید با بانک های مختلف، خدمات کارگزاری و همچنین خدمات امنیتی و کشف تقلب یکپارچه شویم. همه اینها نمونه هایی از تصمیمات تجاری برای تخصص در تنها یک زمینه و عدم حواس پرتی با چیزهایی هستند که می توانیم از شرکای دیگر دریافت کنیم.
اما همه آن ارائه دهندگان third party API و پارادایم های معماری خود را دارند که ما باید به عنوان بخشی از طراحی سیستم خود با آنها کار کنیم. حال، در نهایت، محدودیت نوع سوم ناشی از قوانین و مقررات خاصی است. این محدودیت ها ممکن است جهانی یا مختص یک منطقه جغرافیایی خاص باشند.
به عنوان مثال، در ایالات متحده، اگر در حال توسعه سیستمی هستید که اطلاعات پزشکی یا سوابق بیمار را مدیریت می کند، باید به مقررات HIPAA پایبند باشید که محدودیت های خاصی را برای افرادی که می توانند به داده های بیمار دسترسی داشته باشند، و همچنین امنیت مورد نیاز ما را رعایت کنید. برای ذخیره اطلاعات حساس قرار داده شود.
در اتحادیه اروپا، GDPR محدودیت‌های خاصی را برای سرویس‌های آنلاین در رابطه با نوع داده‌هایی که می‌توانند جمع‌آوری، ذخیره و با اشخاص ثالث درباره کاربرانشان به اشتراک بگذارند، تعیین می‌کند. این مقررات همچنین محدودیت های خاصی در مورد مدت زمان نگهداری برخی از داده ها دارد. بنابراین بسته به کشوری که در آن قصد داریم خدمات خود را ارائه دهیم و صنعتی که خدمات ما به آن تعلق دارد، ممکن است مقررات مختلفی داشته باشیم که بر معماری سیستم ما تأثیر بگذارد.
حال، هنگامی که همه محدودیت ها را شناسایی کردیم، دو ملاحظه وجود دارد که باید در نظر داشته باشیم. اولین ملاحظه این است که ما نباید هیچ محدودیتی را که به ما داده می شود را ساده بگیریم.
منظور این است که ما می‌خواهیم بین محدودیت‌های واقعی که هیچ کاری نمی‌توانیم انجام دهیم و محدودیت‌های خود تحمیلی که می‌توانیم مذاکره کنیم و حتی شاید حذف کنیم، تمایز قائل شویم.
به عنوان مثال، اگر ما با قوانین و مقررات خارجی کار می کنیم، شاید فضای زیادی برای مذاکره وجود نداشته باشد. اما اگر محدودیت‌های بودجه و زمانی را از کسب‌وکار خود دریافت می‌کنیم، شاید جایی برای به تعویق انداختن برخی از مهلت‌ها یا افزایش بودجه وجود داشته باشد. اگر در حال حاضر به سخت افزار خاصی، فروشنده سرویس ابری یا مجموعه خاصی از فناوری ها وابسته شده ایم، شاید این پروژه ای که روی آن کار می کنیم فرصت مناسبی برای بررسی گزینه های دیگری باشد که ممکن است در بلندمدت به سود کسب و کار ما باشد. هنگامی که ما موافقت می کنیم که مجموعه ای از محدودیت ها را بپذیریم، عقب نشینی بسیار سخت است. و اگر متوجه شویم که آن محدودیت‌ها محدودیت‌های واقعی نیستند، معماری کلی ما ممکن است دیگر معنی نداشته باشد. این ما را به دومین ملاحظه می رساند که این است که وقتی محدودیت های خاصی را قبول می کنیم، باید فضای کافی در معماری خود بگذاریم تا از آن محدودیت ها در آینده دور شویم.
به عنوان مثال، اگر ما محدود به یک پایگاه داده خاص هستیم که باید از آن استفاده کنیم یا خدمات third party که باید با آن ادغام کنیم، باید مطمئن شویم که سیستم ما به شدت با آن فناوری خاص یا آن APIهای خاص مرتبط نیست. و اگر در آینده، ما می‌توانیم از فناوری‌های مختلف یا خدمات مختلف استفاده کنیم، به جای اینکه کل سیستم را از ابتدا معماری مجدد کنیم، باید حداقل تغییرات را ایجاد کنیم. وقتی به مبحث بلوک‌های ساختمانی معماری می‌رسیم، نمونه‌های زیادی از ابزارهای خاص و تکنیک‌های کلی را خواهیم دید که چگونه می‌توانیم بخش‌های مختلف سیستم را به‌گونه‌ای جدا کنیم که بتوان به راحتی آنها را به‌طور مستقل جایگزین یا به‌روزرسانی کرد، بدون نیاز به بازسازی مجدد. کل سیستم.
نتیجه گیری
در این بخش، ما در مورد محدودیت های سیستم، یاد گرفتیم. ما ابتدا محدودیت‌های سیستم را به‌عنوان تصمیمی تعریف کردیم که قبلاً یا به طور کامل یا جزئی برای ما اتخاذ شده بود و درجات آزادی خود را محدود می‌کردیم. پس از آن، در مورد سه نوع محدودیت سیستم که عبارتند از محدودیت های فنی، محدودیت های تجاری و محدودیت های قانونی صحبت کردیم. و در نهایت، ما در مورد دو ملاحظه ای که باید به آنها توجه کنیم، هنگام برخورد با محدودیت های سیستم که آنها را ساده نمی بینیم و اطمینان حاصل می کنیم که هیچ گونه پیوند محکمی با آن محدودیت ها نداریم، مورد بحث قرار می دادیم
