معماری و دیزاین ها
- package-oriented design pattern
این دیزاین میگه کدی رو که می زنی سعی کن پکیج کنی ، یعنی بخشی از کدت که reusable هست رو جوری بزن که بتونی ماژولش کنی و بتونی بعدن هم استفاده کنی ، مزایایی که میده اینه که کد خیلی تمییز تر و خانا تر میشه
کاربر راحت میتونه دوباره استفاده کنه و چون قراره بار ها استفاده شه ، هم داکیومنتش قوی تره ، هم مشخصه از چه بخشاییش باید استفاده کنی
کلید های پیاده سازی:
ماژولار کردن یعنی کد رو شکستن و بخش های کوچک تر رو پکیج کرد
اینکپسولیشن یعنی کلاینت به اینتیتی ها و همه جای پروژه دسترسی نداشته باشه و ما مشخص کنیم محدوده دسترسی کار بر رو
component
توی تعریف معماری (…) کامپوننت به اسکوپی می گن که چند تا ویژگی زیر رو داشته باشه .
بشه اون رو ریلیز کرد یعنی به تنهایی قابل استفاده باشه
بتوان نسخه زد براش
همچنین از چند ماژول می شه تشکیل بشه
مثلن دیتابیس یه کامپوننت هست ، بخشی از اکوسیستم هست ، به تنهایی قابل اجراست و هر بار تغییر توش باشه باید ریلیز کرد ،
اینجا باید تصمیم بگیریم : اگر بخواییم تعداد کامپوننت ها رو توی اکوسیستم بالا ببریم ، خوبیش اینه که مثل میکروسرویس کامپوننت های مستقل و کوچیک داریم ، بدیش اینه نگهداری اینا سخت میشه همچنین کامپوننت های down stream راحت میشه تغییر داد زیرا فقط خودشون در صورت ایراد ، مشکل می خورن اما کامپوننت های upstream برای تمامی وابسته هاش مشکل ایجاد می کنه
حالا یه نمودار داریم
-
X : نیاز به تغییرات : یعنی هر چی اون سرویس نیاز به تغییرات داشته باشه تو نمودار بیشتر به سکت ایکس میره
-
Y : هر چی ابسترکت رو توی معماری بیشتر استفاده کرده باشیم . یعنی به جای اینکه کد را خیلی راحت ، تو یه فلت نوشته باشیم ، میل کنیم به سمتی که از اینترفیس و شیگرایی و … بریم ، بیشتر به سمت ایگرگ میل می کنیم
جاییی که x, y نزدیک به صفرن ، مثل پروژه هایی که ۱۰۰ سال پیش زده شدن و همه چی پیوره و سادست ، کسی جرعت نمی کنه بره سمتش و به اون منطقه میگن ، منطقه درد
اگر x, y هر دو تا ته رفته باشن ، یعنی کدی که خیلی از ابسترکت و انتزاعات استفاده کرده و همشن یاز به تغییر داره ، در این حالت خیلی مزخرفه
هر موقع احساس کردید کدی که زدید اینقد جنریکه که به درد همه کار می خوره ، بدونید زیاده روی کردی
architecture role
مظایف یه معمار ، تنها اینی که همه می گن نیست . وظیفه اصلیش تعادل بین موارد زیر :
- sacbility
- security
- performance
- avalibility
- price
ولی مهم ترینش که برنامه نویسا اصلن نمی فهمن اینه که محصول به موقع به مارکت برسه
Time To Market
همچنین باید نیاز های گروه های زیر رو بفهمن :
developer , client , poroduct manager , bussines .
architecture types
soa
خیلی شبیه میکرو سرویسه ، سرویس هااز طریق نتورک با هم ارتباط دارن ، همچنین سایز سرویس ها به نسبت میکرو سرویس بزرگ تر هستند سرویس ها در این معماری بیشتر مونولوتیک هستند و اینترفیس rest , soap دارن
سلسله مراتب
system architecture .sa
حتی شاید سخت افزار هممدیریت شه
system design
دیگه سخت افزار مهم نیست و نرم اقزاری میچینسم
معماری p2p مثل تورنت
مهم ترین ویژگی اینه هیچ وقت از بین نمیره رزیلینس خیلی خوب ، سختیش پیاده سازی و طراحیش هست
استایل بعدی pipe and filter
مثل هدوپ میایم هر بخش از فلو رو جدا میکنیم ، داده که میاد تو ، شاید بخواد برای کامل شدن ، چند تا سرویس رو باید بره تو و خروجی بره سرویس بعد