نوشته شده توسط علی رضائیان
معماری چیست؟
ابتدایی ترین هدف معماری پشتیبانی از چرخه حیات سیستم است. یک معماری خوب فهم, توسعه, نگهداری و دیپلوی کردن سیستم, را آسان میکند. هدف نهایی به حداقل رساندن هزینه چرخه زندگی سیستم و به حداکثر رساندن بهره وری برنامه نویس است. معماران نرم افزار یه سیستم سر و شکل میدهند و آن را می سازند. معماری خوب سیستم را قابل فهم میکند. باعث میشود توسعه , نگهداری و دیپلوی آن راحت باشد. هدف نهایی کم کردن هزینه طول عمر سیستم و بیشتر کردن بهره وری برنامه نویس است.
Development:
یک سیستم نرم افزاری که توسعه آن سخت است احتمالان یک چرخه حیات طولانی و سلامتی ندارد. بنابراین معماری یک سیستم باید توسعه سیستم را برای افرادی که آن را توسعه می دهند راحت کند. *ساختار تیمی متفاوت باعث میشود که تصمیمات معماری متفاوتی هم گرفته شود. تیم های کوچک امکان کار کردن به طور موثر را خیلی راحت میکند و یک سیستم میتواند به شکل یکپارچه بدون هیچ مشکلی کار کند. در سمت دیگر یک سیستمی توسط پنج تیم مختلف توسعه داده شده است که هر تیم هفت توسعه دهنده دارد.فرایند قابل انجام نیست مگر این که سیستم به کامپوننت های مشخصی با رابط های کاربری پایدار قابل اعتمادی تقسیم شوند.اگر هیچ فاکتور دیگری در نظر گرفته نشود, به احتمال زیاد معماری سیستم به پنج جز برای هر تیم تبدیل خواهد شد.
Deployment:
یک سیستم نرم افزاری باید قابل دیپلوی شدن باشد. هزینه زیاد دیپلوی شدن فایده یک سیستم نرم افزاری خوب را کم میکند. یک هدف از معماری نرم افزار این است که با یک عمل بتوان سیستم را پیپلوی کرد. متاسفانه استراتژی دیپلوی کردن در اوایل توسعه نرم افزار به ندرت در نظر گرفته می شود. گاهی معماری را برای فرایند توسعه راحت کند اما فرایند دیپلوی کردن آن را سخت میکند.(Micro-service)
Operation:
اثر معماری بر روی عملکرد سیستم به نسبت فرایندهای توسعه,نگهداری و دیپلوی کمتر چشمگیر است. تقریبان مشکلات عملکرد با اعمال تغییرات بر روی سخت افزار بدون اثر بر روی نرم افزار قابل حل است . معماری هایی که باعث ایجاد مشکل در عملکرد می شوند کمتر هزینه بر هستند تا معماری هایی که در فرایند های توسعه, نگهداری و دیپلوی مشکل دارند. این عبارت نادرست است که گفته شود معماری که برای عملکرد سیستم بهینه شده است قابل استفاده نیست. قطعا قابل استفاده است اما با این نکته که لبه ترازوی هزینه سیستم, به سمت توسعه,نگهداری و دیپلوی سیستم سنگینی میکند. یک معماری خوب نیازهای عملکردی سیستم را در اختیار شما قرار می دهد(به شما نشان میدهد) به عبارت بهتر معماری یک سیستم باعث میشود که عملکرد سیستم به راحتی برای توسعه دهندگان آشکار شود.(قابل فهم باشد). معماری باید عملکرد سیستم را نشان دهد. یک سیستم نرم افزاری باید یوزکیس ها, ویژگی ها و عملکردهای مورد نیاز سیستم برای موجودیت های ابتدایی که برای توسعه دهندگان قابل مشاهده هستند را مشخص کند(bold) کند. چنین معماری هایی فهم سیستم را راحت میکند و موجب کمک به فرایند توسعه و نگهداری می شود.
Maintenance:
نگهداری سیستم هزینه برترین جنبه یک سیستم نرم افزاری است.فرایند پایان ناپذیر اضافه کردن قابلیت های جدید, دنباله اجتناب ناپذیر از نقص ها و باگ ها و اصلاحات باعث میشود تا حجم زیادی از منابع انسانی صرف شود. (( ابتدایی نگهداری به انتخاب و ریسک مربوط میشود.(کندوکاو در نرم افزار موجود) تلاش برای پیدا کردن بهترین استراتژی برای اضافه کردن یک ویژگی جدید یا رفع یک مشکل. حین اعمال چنین تغییراتی احتمال بوجود آمدن مشکلات تصادفی همیشه هست. که باز باعث میشود هزینه زیاد شود. )) تفکر دقیق برای معماری به طور فزاینده ای هزینه ها را کاهش میدهد.با جدا کردن سیستم به یکسری کامپوننت و ایزوله کردن این کامپوننت ها با یکسری اینترفیس های پایدار.باعث می شود تا نقشه راه را برای ویژگیهای آینده روشن شود و همچنین ریسک شکست ها را تا حد زیادی کم می کند.
Keeping options open:
همانطور که در فصول ابتدایی توضیح داده شد.دو نوع ارزش برای یک سیستم وجود دارد: ۱- ارزش عملکرد ۲- ارزش ساختار گزینه دوم دارای اهمیت خیلی بالاتری است چون این هست که یک نرم افزار را نرم میکند. نرم افزار برای نیازهای ما ایجاد شده اند که راهی است سریعتر و آسان تر عملکرد سیستم را تغییر داد. اما منعطف بودن به طور حیاطی به شکل سیستم وابسته است. ترتیب کامپوننت ها, و راهی برای این که این کامپوننت ها ارتباطات داخلی داشته باشند. همه سیستم نرم افزاری می تواند به دو المان عمده تجزیه شود: بیزینس رول ها و جزییات. بیزینس رول ها همه قاعده ها و روش های تجاری را نشان میدهد. این بیزینس رول تا جایی درست است که ارزش واقعی سیستم زنده باشد. جزییات آن چیزهایی است که انسان را نسبت به سیستم تواناتر می کند, و برنامه نویسان برای برقراری ارتباط با بیزینس رول ها از آنها استفاده میکنند, که بر عملکرد بیزینس رول تاثیری ندارد . آنها شامل دستگاه های ورودی و خروجی, دیتابیس, سیستم های وب, سرورها, فریم ورک ها, پروتکل های برقراری ارتباط و غیره است. هدف معمار ساخت شکل برای سیستم, تشخیص بیزینس رول ها به عنوان مهمترین عنصر سیستم, در حالی که جزئیات اصلا ارتباطی به بیزینس رول ندارد. این باعث میشود که اجازه دهد تصمیمات مربوط به جزئیات به تعویق بیفتد.
فکر میکنم که موضوع را متوجه شدید. اگر شما بیزینس رول را بدون متعهد بودن به جزییات حول آن توسعه دهید. شما میتوانید تصمیمات مربوط به جزئیات را به تعویق بیندازید. و شما برای مدت زمان طولانی تر منتظر می مانید که آن تصمیمات را بگیرید. اطلاعات بیشتری که شما دارید باعث میشود آن ها بهتر انتخاب کنید.
این به شما این اجازه را میدهد که تجربیات متفاوتی را امتحان کنید. اگر شما بخشی از یک بیزینس رول را کار می کنید. و آن فراتر از سطح دیتابیس است.شما آن را به چندین دیتابیس می توانید متصل کنید که عملکرد هر دیتابیس را بررسی کنید. این نکته برای وب سرور هم صادق است و سایر مواردی که مربوط به جزئیات می شود. دیگر گزینه های شما باز است. تجربه بیشتری که میتوانید استفاده کنید. چیزهای بیشتری که میتوانید امتحان کنید.و اطلاعات بیشتری خواهید داشت وقتی که شما به نقطه ای رسیدید که این تصمیمات دیگر به اشتباه گرفته نمیشوند.
یک معمار خوب وانمود میکند این تصمیمات گرفته نشود. یک معمار خوب تعداد تصمیمات گرفته نشده است را حداکثر می کند.