گپ فنی امشب داخل گروه با سعید جان ، در خصوص استوریج فایلهای حجیم در بستر وب


به زودی میتهای تخصصی رو مجدد شروع میکنیم و با همون قدرت ماه های اول گپ برمیگردیم و چندین ساعت با حضور سعید کد میبینیم و گفتگو خواهیم کرد


@code_crafters

در پیرو گپ دیشب در گروه بابت minio مقاله زیر رو بخونید


https://blog.min.io/selecting-hardware-for-minio-deployment/

گپ امشب گروه با سعید جان
موضوع گپ:
تحلیل و بررسی فنی سرویس هایی مانند پرداخت، سفارش، سبد خرید و چالش های یک سیستم فروشگاهی چند منطوره با تجربه های شخصی

برخی از مباحث گفته شده:
- چگونگی عملکرد درگاه های پرداخت انلاین
- چگونگی و چالش های طراحی سرویس فروشگاهی، خرید، سبد خرید و انبار داری
- صحبت در باره retry handling و rollback تغییرات و Saga state machine
- بررسی زنده یک اپلیکیشن دارای فروشگاه، تحلیل محصولات و اپلیکیشن های مشابه
- توضیح درباره کیف پول مجازی، روش های پرداخت، پرداخت
- بحث مدیریت همزمانی، اعتبار سنجی خرید ها، کنترل و رزرو موجودی و Checkout
- پرسش و پاسخ سوالات مرتبط دوستان

بزودی میت‌های تخصصی رو مجدد شروع میکنیم


@code_crafters

در بخشی از گپ امشب
سوالی مطرح شد که هندل کردن اون وابسته به معماری ما داشت و طی توضیحات گفتم معماری رو براتون میزارم


این بیس معماری سرویس پرداخت هستش که به شدت منعطف می‌باشد و در مقابل تغییرات و بزرگ شدن و افزودن هر نوع دیگری از فروش به آن قابلیت ارجاعی داره و به راحتی میتونید سایر موارد و بخش‌های خودتون رو بهش اضافه کرده و گسترده‌ترش کنید


تحلیل خودتون رو راجبش در کامنت‌ها بزارید تا حرف بزنیم و نسبت بهش بیشتر شناخت پیدا کنید

@code_crafters

مقاله زیر رو در خصوص رعایت یکسری اصول کدزنی در پایتون بخونید ،سازمانهای بزرگ خروجی همچین چیزی ازتون انتظار دارن


@code_crafters




https://google.github.io/styleguide/pyguide.html

#مقیاس_پذیری و چالش های آن - پارت 1
Horizontal & Vertical #Scaling ⚖️

زمانی که فرآیند تولید نرم افزار به مرحله Production می‌رسد و اپلیکیشن روی سرور می‌رود، چالش‌ها و مخاطرات جدیدی برای صاحبان آن ایجاد می‌شود. ما در عصری هستیم که استفاده از اینترنت به سبک زندگیمان تبدیل شده. بنابراین پس از معرفی اپلیکیشن یا وبسایت، کاربران آن به سرعت افزایش پیدا می‌کند.
زمانی فرا می‌رسد که سیستم دیگر توان هندل کردن حجم بازدیدکنندگان و پردازش درخواست ها را ندارد.
در مواردی هم حجم دیتا به حدی می‌رسد که سیستم نمی‌تواند آن را در پایگاه داده خود ذخیره کند. در این گونه موارد، زمان آن فرا رسیده که محصول Scale یا مقیاس پذیر شود.
معمول ترین راهکار، مقیاس پذیری عمودی یعنی افزایش منابع سخت افزاری مانند RAM, CPU است اما در نرم‌افزار های بزرگتر، مقیاس پذیری عمودی تا حدی کارساز است.
از یک حدی به بعد تک سرور شما قادر به افزایش منابع نخواهد بود و یا صرفه اقتصادی نخواهد داشت. کما اینکه vertical Scaling محدودیت هایی مانند دیسک و شبکه را مقیاس پذیر نمیکند. (به خصوص پهنای باند در سرور های داخل که سرشار از اختلال و از نسل 3G است!)

بنابراین مقیاس پذیری افقی با افزودن سرور های بیشتر (که زین پس به آنها Node خواهیم گفت) و تقسیم بار بین انها ( Load Balanacing) راه حل بهتری خواهد بود. چرا که هم افزایش سرور ها ارزان تر خواهد بود (به نسبت خرید منابع حافظه و پردازنده بیشتر) و هم هر سرور مستقلا میتواند به‌ مقدار نیاز مقیاس پذیری عمودی هم داشته باشد (هر سرور منابع اختصاصی متفاوتی از حافظه ram، پردازنده، iops دیسک و پهنای باند / پورت شبکه داشته باشد)
تا به اینجا اصلی ترین تفاوت های دو مدل مقیاس پذیری را بررسی کردیم. اما همیشه چالش ها،‌ مزایا و معایبی هم وجود دارد که در جایگاه یک مهندس نرم افزار حرفه ای و معمار سیستم، ما باید با علم به این مباحث برای یک کسب و کار تصمیم بگیریم.

یکی از چهار هدف اصلی مقیاس پذیری، توسعه پذیر تر کردن یک نرم افزار است.
در مقیاس پذیری افقی مهمترین و اصلی ترین چالش های پیش رو مباحثی مانند همزمانی در عملیات ها، یکپارچگی داده ها، از بین بردن Single point of failure و کاهش گلوگاه ها است.
همانطور که در بالاتر اشاره شد در مقیاس پذیری افقی ما بجای تکیه بر سخت افزار محدود یک سرور، به طرف توزیع بار و کلاستر سرویس ها بر روی چند سرور (نود) متعدد میرویم.

فرض کنید نرم افزاری دارید که متشکل از ده ها میکروسرویس‌ و ده ها دیتابیس و ابزار مختلف میباشد. هر کدام ازین میکروسرویس ها بر روی سرور های 1 الی 5 در حال اجرا هستند. همچنین ممکن است هر یک ازین سرویس ها نیاز به replication و load balancing پیدا کنند (هدف از مقیاس پذیری افقی).
در اینصورت علاوه بر این که کلاستر سرور های شما میبایستی در یک شبکه داخلی یا خصوصی پایدار و قابل اتکا با هم در ارتباط باشند، بایستی بتوانند بصورت پایدار عملیات های خود را انجام دهند.
برخی از پارامتر های پایداری:
- درخواست های همزمان متعدد نباید منجر به پاسخ های مختلف شوند.
- داده های خروجی باید جدیدترین داده های موجود باشند.

به عنوان مثال، سرویس سفارش یا احراز هویت مان را مقیاس پذیر کردیم و لود بالانسینگ تعیین میکند هر بار درخواست ها به کدام node / سرور ارسال شود.
در صورتی که دو یا چند کاربر بطور همزمان قصد دسترسی به یک ریسورس مشترک (فایل / دیتابیس / etc) داشته باشند مشکلاتی همچون همزمانی یا concurrency و شرایط مسابقه یا race conditions پدیدار خواهد شد.

علاوه بر همزمانی، حفظ یکپارچگی داده ها و جلوگیری از بروز رفتارهای نادرست در سیستم بسیار مهم است.

در مطلب بعدی (پارت 2 مقیاس پذیری)، به برخی شیوه های مدیریت این چالش ها و تجربه های شخصی میپردازیم.

بیشتر بخوانید (مقالات / مفاهیم مرتبط):
دسترسی پذیری بالا HA
گلوگاه Bottleneck
خوشه ها Cluster
تئوری CAP
مقیاس پذیری Scalability
سیستم های توزیع شده Distributed Systems

#مهندسی_نرم‌افزار #معماری
#software_engineering #architecture #Scalability #distributed_systems #devops #infrastructure

@csharpfriends @Code_Crafters

Example of Microservices System design template overview

#microservices #Scaling #bestpractice #architecture #distributed_systems #مهندسی_نرم‌افزار

- برخی از شماتیک‌ معماری دیگر پروژه های معروف در کامنت ها

@csharpfriends @Code_Crafters

دورنمای بسیار ساده و خلاصه لودبالانسینگ در معماری و طراحی میکروسرویس ها
در مطالب آینده درباره لودبالانسینگ یا توزیع بار صحبت خواهیم کرد
#microservices #load_balancing #api_gateway #Scaling #architecture #مهندسی_نرم‌افزار

@csharpfriends @Code_Crafters

میکروسرویس و حکمرانی soa، در ادامه مباحث مربوط به سیاست‌های سازمانی soa در ادامه میریم به سراغ سیاست‌های امنیتی

امنیت بخش جدا ناپذیر دنیای امروزی هست و مشتریان ما خواهان امن بودن اطلاعات حساس خود در سامانه شما هستند برای مثال اطلاعات شخصی و موارد مالی افراد، مشتریان انتظار دارن که شما امنیت اطلاعات رو محفوظ تضمین کنید


سیاست‌های امنیتی

یک کانال ارتباطی را برای داده های حساس رمزگذاری کنید: هنگامی که یک مصرف کنندهش به سرویسی دسترسی پیدا می کند که حاوی اطلاعات حساس است یا به آن نیاز دارد (به عنوان مثال، اطلاعات کارت اعتباری یا جزئیات شخصی)، این سرویس باید ارتباطات را به صورت ایمن مدیریت کند. این سیاست برای شروع خوب است. با استفاده از آن می توانید مطمئن شوید که ارتباطات را در سطح جابجایی رمزگذاری می کنید.

یکپارچگی و عدم انکار پیام را تأیید کنید: مهم است که بتوانید تشخیص دهید که آیا مشکلی در پیام وجود دارد. ممکن است در حین جابجایی تغییر داده شود، یا ممکن است شخصی جعل هویت شخص دیگری باشد. اگر مطمئن هستید که خدمات شما با این خط‌مشی مطابقت دارد، می‌توانید تضمین کنید که فقط پیام‌هایی را پردازش می‌کنید که می‌دانید معتبر هستند.

از یک سیستم هویت متمرکز برای احراز هویت استفاده کنید: احراز هویت مصرف کنندگان (یا کاربران داخلی شما) چیزی است که تقریباً همه خدمات به آن نیاز دارند. اغلب این برای هر سرویس دوباره اختراع می شود. با استفاده از یک سیستم هویت متمرکز، می توانید مطمئن شوید که هر سرویس از سیاست های سختگیرانه ای که در مورد شناسایی تعیین شده است پیروی می کند.

از یک سیستم هویت متمرکز برای مجوز استفاده کنید: قوانین مشابهی برای مجوز اعمال می شود. این اغلب چیزی است که در گذشته به برنامه ها اضافه می شود و نگهداری از آن اغلب دشوار است. با متمرکز کردن مجوز می توانید مطمئن شوید که همه سرویس ها از دستورالعمل های مجوز یکسانی که در سازمان تعریف شده است پیروی می کنند.


وب سرویس‌ خود را بشناسید و یکپارچگی پیام را در آن رعایت و پیاده سازی کنید (SOAP, REST, ...) برای مثال در REST این مسئله با https فراهم گشته اما اگر جایی این پروتکل نبود میتوانید از HMAC استفاده کنید، کمپانی های بزرگی مانند azure, aws, ... از این موضوع برای سرویس REST خود استفاده میکنند و عموما یک رویکرد مشابه دارن، یک سرویس تولید HMAC بالا بیاورید کاربر قبل از ارسال پیام به شما یک کلید گرفته و همراه پیام برای شما ارسال میکند شما پیام را گرفته و بر اساس پارامترهای خود از سرویس HMAC کلید رو میگیرید حالا دو کلید HMAC رو باهم مقایسه کرده و یکپارچگی و یا عدم یکپارچگی رو تایید کنید، اما سوال پارامترهای ورودی ما چه چیزهایی باشد، AWS به شکل زیر عمل میکند

روش HTTP:
با REST نوعی از روش HTTP که اجرا می کنید رفتار سمت سرور را مشخص می کند.  DELETE به یک URL خاص به طور متفاوتی با GET به آن URL مدیریت می شود

هدر Content-MD5:
این هدر HTTP یک هدر استاندارد HTTP است.این یک هش MD5 از بدنه درخواست است.اگر این هدر را در تولید کد HMAC قرار دهید، یک مقدار HMAC دریافت می کنید که با تغییر بدنه درخواست تغییر می کند

هدر Content-Type: 
هدر Content-Type یک هدر مهم هنگام برقراری تماس های REST است. بسته به نوع رسانه، سرور می تواند به یک درخواست پاسخ متفاوتی بدهد.بنابراین باید در HMAC گنجانده شود.

 هدر تاریخ:
شما همچنین تاریخ ایجاد درخواست برای محاسبه HMAC را درج می کنید. در سمت سرور می توانید مطمئن شوید که تاریخ در حین انتقال تغییر نکرده است.  علاوه بر این می توانید قابلیت انقضای پیام را در سرور اضافه کنید.

 مسیر روش HTTP:
بخشی از مسیر URL که فراخوانی شده است نیز در محاسبه HMAC استفاده می شود، زیرا یک URI منبعی را در REST شناسایی می کند.

یک سیستم احرازهویت مرکزی و مجوزدهی (authentication, authorization) راه اندازی کنید SSO (دقت کنید ممکن سیستم مجوز هی شما متفاوت از هویت سنجی باشد این بستگی به سیستم شما دارد) (در کتاب که بر اساس جاوا نوشته شده، پلتفرم openam را معرفی و پیش برده، در پست‌های قبلی کانال راجب keycloak صحبت شد)


#microservice
#soa

@code_crafters

چهل نکته درباره Linux Server Hardening
۱. رمزنگاری ارتباطات در سرور لینوکس:

تمام داده‌هایی که از شبکه ارسال می‌شوند، قابل شنود هستند. بهتر است همیشه داده‌های ارسالی را با رمزنگاری کردن، محافظت کنیم.

برای انتقال فایل می‌توان از scp, ssh, rsync و sftp استفاده کرد که همگی رمزنگاری دارند. همچنین می‌توان درایو سرور دیگر یا home کاربری خود را با استفاده از sshfs یا fuse محافظت شده مانت کرد.

برای رمزنگاری داده‌های خروجی، می‌توان از گنوپی‌جی استفاده کرد. همچنین برای اتصالات شبکه‌ای می‌توان از اپن‌وی‌پی‌ان یا تینک استفاده کرد که ارتباطات شبکه‌ای را رمزنگاری می‌کنند.

برای رمزنگاری وب‌سرورها نیز می‌توان از الایت‌تی‌پی‌دی، آپاچی و انجین‌اکس با استفاده از SSL استفاده کرد.‌
‌
‌
‌
۲. از استفاده از سرویس‌های FTP، Telnet و Rlogin/Rsh در لینوکس خودداری کنید!!

از استفاده از سرویس‌های FTP، Telnet و Rlogin/Rsh در لینوکس خودداری کنید.
در بسیاری از تنظیمات شبکه، نام کاربری‌ها، رمزهای عبور، دستورات FTP/telnet/rsh و فایل‌های انتقالی توسط هر فردی که در همان شبکه حضور دارد، با استفاده از یک برنامه (Packet Sniffer)، قابل ضبط می‌باشند. راه حل معمول برای این مشکل استفاده از OpenSSH، SFTP یا FTPS (FTP over SSL) است که به FTP رمزنگاری SSL یا TLS را اضافه می‌کنند.

برای حذف سرویس‌های قدیمی و غیرمطمئن مانند NIS، rsh و سایر سرویس‌ها، دستور yum زیر را وارد کنید:

yum erase xinetd ypserv tftp-server telnet-server rsh-server

اگر از سرور مبتنی بر دبیان/اوبونتو استفاده می‌کنید، از دستور apt-get/apt برای حذف سرویس‌های ناامن استفاده کنید.

sudo apt-get --purge remove xinetd nis yp-tools tftpd atftpd tftpd-hpa telnetd rsh-server rsh-redone-server

توضیح:
این بخش از متن به شما هشدار می‌دهد که استفاده از سرویس‌های FTP، Telnet و Rlogin/Rsh در لینوکس باعث بروز ریسک امنیتی می‌شود. در شبکه‌های عمومی، اطلاعات کاربران، رمزهای عبور، دستورات و فایل‌های انتقالی به راحتی توسط افرادی که در همان شبکه حضور دارند قابل ضبط و دسترسی هستند. برای حل این مشکل، توصیه می‌شود از سرویس‌های امن‌تر مانند OpenSSH، SFTP و FTPS استفاده کنید. همچنین، دستورات لازم برای حذف سرویس‌های قدیمی و غیرمطمئن از سیستم‌عامل لینوکس نیز در اینجا آورده شده است.

packet sniffer:
برنامه (Packet Sniffer) یک نوع نرم‌افزار یا دستگاه است که بسته‌های داده‌ای که در یک شبکه عبور می‌کنند را ضبط و تجزیه می‌کند. هدف اصلی این برنامه‌ها، مشاهده و آنالیز ترافیک شبکه است.

وقتی داده‌ها در یک شبکه ارسال می‌شوند، آنها به شکل بسته‌های کوچکتر تقسیم می‌شوند که حاوی اطلاعات مانند آدرس مبدأ و مقصد، داده اصلی و سایر اطلاعات مربوطه هستند. برنامه‌های packet sniffer این بسته‌ها را دریافت کرده و می‌توانند اطلاعات مفیدی مانند نام کاربری، رمز عبور، دستورات ارسالی و فایل‌های انتقالی را از آنها استخراج کنند.

استفاده از برنامه‌های packet sniffer در شبکه‌های عمومی یا شبکه‌هایی که به آنها دسترسی عمومی دارید، ممکن است برای جاسوسی یا به دست آوردن اطلاعات حساس به کار گرفته شود. با استفاده از این برنامه ها، فرد مورد نظر می‌تواند بسته‌های شبکه را ضبط کند و اطلاعات را بررسی کند، حتی اگر این اطلاعات به طور عادی رمزنگاری شده باشند.

از طرف دیگر، برنامه‌های packet sniffer نیز می‌توانند به عنوان ابزارهای مفیدی برای آنالیز و عیب‌یابی شبکه استفاده شوند. با استفاده از این برنامه‌ها، می‌توانید ترافیک شبکه را بررسی کنید، مشکلات را تشخیص دهید و عملکرد بهتری را برای شبکه خود فراهم کنید.

برنامه‌های packet sniffer معمولاً در قالب نرم‌افزارهای مختلفی مانند Wireshark، tcpdump، WinPcap و Capsa قابل دسترسی هستند و در سیستم‌عامل‌های مختلفی مانند لینوکس و ویندوز قابل استفاده هستند.‌
‌
‌
‌
۳. کاهش نرم افزار های نصب شده به منظور کاهش آسیب پذیری در لینوکس:

آیا واقعا نیاز به همه نوع سرویس هایی که نصب شده اند دارید؟ با حذف نرم افزار های اضافی امنیت و عملکرد سرور خودتون رو بهبود ببخشید.
از مدیر بسته RPM مانند yum یا apt-get و/یا dpkg استفاده کنید تا مجموعه‌ای از نرم‌افزارهای نصب شده روی سیستم را بررسی کنید. تمامی بسته‌های ناخواسته را حذف کنید.

yum list installed
yum list packageName
yum remove packageName
یا
dpkg --list
dpkg --info packageName
apt-get remove packageName‌
‌
‌‌

#linux
#hardning

@code_crafters

اجرا هر سرویس در یک سیستم نمونه مجازی:
اجرای سرویس‌های شبکه مختلف را در سرورها یا نمونه‌های مجازی جداگانه انجام دهید. این محدودیت تعداد سرویس‌های دیگری که ممکن است قربانی شود را محدود می‌کند. به عنوان مثال، اگر یک حمله‌کننده قادر به بهره‌برداری موفق از یک نرم‌افزار مانند Apache شود، او می‌تواند به تمامی سرور شامل سرویس‌های دیگری مانند MySQL/MariaDB/PGSql، سرور ایمیل و غیره دسترسی پیدا کند.

مثال:
فرض کنید شما یک سرور لینوکس دارید که شامل سرویس‌های Apache و MySQL است. به جای اجرای هر دو سرویس روی یک سرور، شما می‌توانید سرور Apache را روی یک سیستم مجازی و سرور MySQL را روی یک سیستم مجازی جداگانه اجرا کنید. اینکار به شما امکان می‌دهد که سرویس‌های مختلف را در محیطی مستقل و جداگانه اجرا کنید. در نتیجه، اگر سرویس Apache مورد عنایت قرار گیرد، دسترسی به سرویس MySQL در سیستم مجازی جداگانه محدود خواهد شد و امنیت سیستم شما حفظ خواهد شد.

استفاده از کانتینر داکر می‌تواند یک روش مناسب برای پیاده‌سازی این رویکرد باشد. با استفاده از کانتینرها، شما می‌توانید هر سرویس شبکه را در یک کانتینر جداگانه اجرا کنید. این کانتینرها محیطی مستقل از یکدیگر ایجاد می‌کنند و از هم جدا بوده و امکان دسترسی به سرویس‌های دیگر را محدود می‌کنند.

برای پیاده‌سازی این رویکرد با استفاده از کانتینر داکر، شما می‌توانید به شکل زیر عمل کنید:

1. ایجاد یک تصویر داکر برای هر سرویس شبکه: شما باید یک تصویر داکر برای هر سرویس شبکه مورد نظر ایجاد کنید. این تصویر شامل تنظیمات و پیکربندی‌های مربوط به سرویس شبکه خاص است.

2. اجرای کانتینرها: با استفاده از ابزار داکر، شما می‌توانید کانتینرهای مربوط به هر سرویس را بر اساس تصاویر داکر ایجاد شده، اجرا کنید. هر کانتینر در یک محیط مجازی جداگانه اجرا می‌شود و از هم جدا است.

3. پیکربندی شبکه: برای ارتباط بین کانتینرها و اجرای سرویس‌های شبکه، شما می‌توانید شبکه‌های داکر را پیکربندی کنید. این شبکه‌ها به کانتینرها امکان می‌دهند تا از طریق شبکه با یکدیگر ارتباط برقرار کنند.

با این رویکرد، شما هر سرویس شبکه را در یک کانتینر جداگانه اجرا می‌کنید و از ارتباط مستقیم بین سرویس‌ها جلوگیری می‌کنید. اگر یک سرویس تحت حمله قرار بگیرد، تأثیر آن روی سایر سرویس‌ها محدود خواهد بود و امنیت سیستم شما حفظ می‌شود.‌
‌
‌‌

۵. نگهداری از هسته لینوکس و بروز بودن نرم افزار ها:

اعمال پچ‌های امنیتی بخش مهمی از نگهداری سرور لینوکس است. لینوکس ابزارهای لازم برای به‌روزرسانی سیستم شما را فراهم می‌کند و همچنین امکان به‌روزرسانی آسان بین نسخه‌ها را فراهم می‌کند. تمامی بروزرسانی‌های امنیتی باید اعمال شوند. از مدیر بسته RPM مانند yum و/یا apt-get و/یا dpkg برای اعمال تمامی بروزرسانی‌های امنیتی استفاده کنید.

# yum update
یا
# apt-get update && apt-get upgrade

شما می‌توانید Red Hat / CentOS / Fedora Linux را به‌گونه‌ای پیکربندی کنید که از طریق ایمیل اطلاعیه‌های بروزرسانی بسته yum را دریافت کند. یک گزینه دیگر نیز استفاده از کرون جاب برای اعمال تمامی بروزرسانی‌های امنیتی است. در Debian / Ubuntu Linux می‌توانید از apticron برای ارسال اطلاعیه‌های امنیتی استفاده کنید. همچنین امکان پیکربندی بروزرسانی‌های بدون نیاز به تداخل برای سرور Debian / Ubuntu Linux با استفاده از دستور apt-get/apt نیز وجود دارد:

$ sudo apt-get install unattended-upgrades apt-listchanges bsd-mailx

نحوه پیکربندی apticron:

برای استفاده از apticron در سرور Debian/Ubuntu Linux و ارسال اطلاعیه‌های امنیتی، می‌توانید مراحل زیر را دنبال کنید:

1. نصب apticron: ابتدا باید برنامه apticron را در سیستم خود نصب کنید. برای این کار، از دستور زیر استفاده کنید:

sudo apt-get install apticron

2. پیکربندی apticron: پس از نصب، باید فایل تنظیمات apticron را پیکربندی کنید. فایل پیکربندی برای apticron در مسیر /etc/apticron/apticron.conf قرار دارد. باز کنید و ویرایش کنید:

sudo nano /etc/apticron/apticron.conf

3. تنظیمات ایمیل: در فایل تنظیمات، بخشی با عنوان EMAIL وجود دارد. در این بخش، آدرس ایمیل خود را به جای [email protected] قرار دهید. برای مثال:

EMAIL="[email protected]"

4. تنظیمات بسته‌های اطلاعیه‌های امنیتی: در فایل تنظیمات، بخشی با عنوان PACKAGE_NAMES وجود دارد. در این بخش، باید نام بسته‌هایی که می‌خواهید اطلاعیه‌های امنیتی آنها را دریافت کنید را مشخص کنید. برای مثال:

PACKAGE_NAMES="apache2 mysql-server php"

5. ذخیره و بستن فایل تنظیمات: پس از اعمال تغییرات، فایل را ذخیره کنید و ببندید

#linux
#hardning

@code_crafters

در ادامه حکمرانی soa میرسیم به سراغ تست نویسی ،اما چرا این بخش وجود دارد، سوا از اینکه تست نویسی در قلمرو soa نمیگنجد، اما این یک الزام همیشگی می‌باشد که باید در تمام نقاط و کدهای خود انجام دهید تا از درستی و سلامت کار کرد کدهای خود آگاه شوید و سرویس‌های خود را از راه دور فرا بخوانید تا مطمئن شوید به درستی کار میکنن

سیاست‌های تست نویسی:

لایه ادغام: 
تست کنید تا ببینید آیا تمام اجزای مختلف همانطور که انتظار می رود با هم کار می کنند یا خیر.  این ممکن است شامل تماس هایی با استفاده از چندین سرویس باشد. 

 لایه سرویس از راه دور:
تست کنید تا ببینید آیا می توانید با لایه راه دور سرویس تماس بگیرید و آیا این لایه به درستی تبدیل داده ها از فرمت راه دور به فرمت داخلی را انجام می دهد یا خیر.  برای این کار باید یک الگو از لایه سرویس خود بسازید، اما بعداً در مورد آن بیشتر توضیح دهید.

 لایه منطقی:
 در اینجا شما تست می کنید که آیا منطق تجاری لایه سرویس و مدل به درستی پیاده سازی شده است یا خیر.  برای آزمایش این لایه، دوباره باید از اشیاء ساختگی، این بار برای لایه داده استفاده کنید.

 لایه داده:
در لایه داده شما آزمایش می کنید که آیا اطلاعات به درستی باقی می مانند یا خیر.

در بخش مربوط به لایه منطقی و لایه داده اگر شما unittest نوشته باشید حجت رو تموم کرده‌اید، اما میتوانید و بهتر است با mock نیز تست کنید

در تست لایه ارتباطی خود(لایه راه دور) دو موضوع اهمیت دارد، یک تست پروتکل ارتباطی بین سرور و مشتری، دو تست تبدیل داده‌های بین سرور و مستری و جاساز آن به درستی(در این تست شما به ذخیره سازی داده اهمیت نمیدهید)

تست ادغام(integration): سرویس های شما با هم در ارتباط هستند و این نیازمند تست می باشد تا مطمئن شوید جریان شما صحیح و به درستی کار میکند


در ادامه مبحث این تست‌های شما نیست که تنها اهمیت دارد بلکه کیفیت کدها نیز اهمیت بالای دارد، که کدام بخش از کد شما در سطح بهتری کار میکند(در کتاب از ابزار sonar برای بررسی کیفیت کد اسم برده) معیارهای خروجی این برنامه میتواند نقطه شروع سیاست گذاری ما باشد:

بیانیه:
 ما می خواهیم خدمات ما حداقل سطح کیفی قابل اندازه گیری داشته باشد.  سرویس ها باید به خوبی تست شده و استانداردهای کدگذاری را که ما تعریف کرده ایم تایید کنند.  ما سطوح زیر را از انطباق تعریف می کنیم:
 پوشش کد: حداقل 80% .موفقیت در تست: 100% .مسائل امنیتی: 0 .رعایت قوانین: 90% 

منطق:
 در سازمان ما برنامه ها و خدمات مختلفی داریم.  آنها توسط افراد مختلف و تیم های مختلف ایجاد و نگهداری می شوند.  برای اینکه افراد بتوانند کد دیگران را بخوانند و آن را حفظ کنند، می‌خواهیم مطمئن شویم که کد به‌صورت یکسان ایجاد شده است.
 علاوه بر این، ما می خواهیم سطح خاصی از کیفیت را در خدمات خود داشته باشیم.  این به حفظ یک پایه کد با کیفیت بالا کمک می کند و منجر به صرف زمان کمتری برای کار مجدد و رفع اشکال می شود

 پیامدها:
کد باید به طور گسترده آزمایش شود تا مطابق با خواسته های کیفیت خاص باشد. یک ساخت با کیفیت باید برای بررسی خودکار کیفیت کد تنظیم شود.

مورد بعدی توسعه برای cloud می باشد که در پست‌های قبلی در خصوص صفات و ویژگی‌های آن کامل توضیح داده شده است

لینک تکمیلی پست

#microservice
#soa

@code_crafters

در ادامه مباحث حاکمیت soa میرسیم به سیاست‌های زمان اجرا، بعد از اتمام و اجرا کردن سرویس وقت آن فرا رسیده که نظارت جامعی بر روی انها و بررسی مطابقت آن با سیاست‌های تعریف شده برسیم و چرخه عمر سرویس مشخص گردد، جهت نظارت بر زمان اجرا شما اینکار رو با ابزارهای مختلفی انجام میدهید و گزارشات آنرا بررسی میکنید(در کتاب در این فصل به پلتفرم BAMOS پرداخته و راجب آن صحبت میکند) و از سرویس‌های مانیتورینگ استفاده نموده و رویدادهای خاصی رو تعریف کرده تا سیستم برای شما طبق آن گزارش تهیه کند


چرخه عمر سرویس به دلایل زیر قابل اهمیت می‌باشد:

 ■ به شناسایی خدماتی که نیاز به ایجاد یا به‌روزرسانی دارند کمک می‌کند، زیرا یک نمای کلی از تمام سرویس‌هایی که در حال حاضر در حال تولید هستند را ارائه می‌دهد

 ■ کمک می کند تا مطمئن شوید که تمام اقدامات لازم قبل از تولید یا منسوخ شدن یک سرویس انجام شده است

 ■ تعیین خط مشی هایی که در هر مرحله باید رعایت شود استفاده کرد.

چرخه عمر سرویس معمولاً در چهار فاز متمایز شناسایی می‌شوند: مدل‌سازی، مونتاژ، استقرار و مدیریت

فاز مدل:
در این فاز شما دو مرحله دارید، یک به الزامات تجاری که باید برآورده شود نگاه کنید(بررسی درخواست مشتریان و آنچه که انها نیاز دارند) دو شناسایی خدمات مورد نیاز برای ارائه این قابلیت تجاری(آیا این قابلیت از قبل در سیستم ما و سرویس‌های ما وجود دارد؟؟؟آیا نیاز به توسعه یک سرویس جدید داریم؟؟؟آیا میشه یکی رو تمدید کرد؟؟)

فاز مونتاژ:
در این مرحله شما الزامات خدمات تجاری در فاز قبل رو دریافت کرده و آنرا به یک سرویس تبدیل میکنید و منتشر میسازید

فاز استقرار:
پس از ایجاد سرویس آن را در یک ظرف گذاشته و مستقر میکنید تا شروع به تبادل با سیستم نموده و یکپارچه گردد

فاز مدیریت:
مرحله نهایی مرحله مدیریت است. در این مرحله به نحوه عملکرد سرویس در زمان اجرا نگاه می کنید. شما تعیین می‌کنید که آیا خط‌مشی‌هایی که برای این سرویس تعریف کرده‌اید برآورده می‌شوند، آیا ممکن است به عملکرد جدیدی نیاز باشد یا خیر، و آیا همه خدماتی که تعریف کرده‌اید با اهداف تجاری تعیین‌شده در مرحله مدل مطابقت دارند یا خیر. اگر نیازهای جدیدی وجود داشته باشد یا اگر باید تغییراتی در سرویس موجود شما ایجاد شود، چرخه جدیدی را در فاز مدل شروع می کنید


سیاست‌های چرخه عمر سرویس:

شناسایی فرآیند کسب و کار:
در این مرحله شما تعریف می‌کنید که اگر می‌خواهید الزامات تجاری جدید را برآورده کنید، کدام فرآیندهای تجاری ممکن است نیاز به تغییر داشته باشند. این مرحله چرخه عمر قبل از تعریف هر سرویسی رخ می دهد، بنابراین در چرخه عمر سرویسی که در مخزن تعریف می کنید گنجانده نمی شود

 شناسایی خدمات مورد نیاز: 
پس از شناسایی فرآیندهای تجاری که درگیر هستند، می‌توانید از آن‌ها برای شناسایی خدماتی که ممکن است نیاز به بروزرسانی یا ایجاد جدید داشته باشند استفاده کنید.  مانند مرحله قبل، این مرحله نیز خارج از رجیستری WSO2 نگه داشته می شود، زیرا در این مرحله منابعی را در مخزن ایجاد نکرده اید

 قرارداد را تعریف کنید در این مرحله شما خدماتی که باید ایجاد کنید را می شناسید.  در این مرحله شما قرارداد را تعریف خواهید کرد (یک WSDL در مورد WS-* و مجموعه ای از اسناد در مورد REST)

 ثبت قرارداد:
بعد از اینکه قرارداد را تعریف کردید، می توانید آن را در مخزن WSO2 ثبت کنید

 تحقق سرویس:
 با قرارداد موجود در مخزن، می توانید اجرای سرویس را آغاز کنید.  در این مرحله ممکن است تغییرات کوچکی در قراردادی که قبلاً در مخزن ذخیره شده است ایجاد کنید

سرویس را آزمایش کنید:
قبل از اینکه سرویس را اجرا کنید تا مصرف کنندگان سرویس شما بتوانند از آن استفاده کنند، ابتدا باید سرویس را آزمایش کنید. 

 استقرار سرویس:
 پس از آزمایش، در نهایت می توانید سرویس را در یک کانتینر مستقر کنید و به مصرف کنندگان سرویس اطلاع دهید که می توانند از آن استفاده کنند

 سرویس در دسترس:
پس از استقرار، سرویس در دسترس است.  در این مرحله سرویس نظارت خواهد شد تا ببینیم آیا با سیاست های زمان اجرا مطابقت دارد یا خیر

 سرویس منسوخ شده:
هنگامی که سرویس دیگر استفاده نمی شود یا نسخه جدیدی مستقر می شود، این سرویس می تواند به عنوان منسوخ شده علامت گذاری شود.  در این صورت، مصرف کنندگان خدمات همچنان می توانند از این سرویس استفاده کنند اما باید به سرویس دیگری منتقل شوند، زیرا این سرویس به زودی بازنشسته خواهد شد

 سرویس بازنشسته شد:
پس از اینکه یک سرویس منسوخ شد و باید حذف شود، سرویس را بازنشسته می‌کنید.  اگر سرویسی بازنشسته شود، مصرف کنندگان خدمات دیگر نمی توانند به آن دسترسی داشته باشند.

#microservice
#soa

@code_crafters

سوالات مربوط به سیاست‌های بالا:

اولیه: 
آیا قراردادی تعریف شده است؟
آیا مستندات نوشته شده است؟

 ثبت شده: 
آیا سرویس ایجاد شده است؟
آیا کیفیت کد و پوشش آزمایشی با خط مشی مطابقت دارد؟

 در تست:
آیا تست ادغام با سایر اجزا به پایان رسیده است؟
آیا تست ادغام با مصرف کننده خدمات به پایان رسیده است؟
آیا سرویس در محیط تولید مستقر شده است؟
آیا پیکربندی سرویس به روز شده است؟

موجود:
آیا مصرف کنندگان در مورد استهلاک مطلع شده اند؟
آیا پیکربندی سرویس به روز شده است؟

 منسوخ شده:
آیا مصرف کنندگان در مورد بازنشستگی خدمات مطلع شده اند؟

 بازنشستگی:
چرخه عمر پایان سرویس

علاوه بر سرویس‌های ما که دارای چرخه عمر هستند، برخی از سیاست‌های ما نیز دارای یک عمر هستند و این ممکن است به دلایل مختلی از قبیل اعمال سیاست جدید، ایجاد خط مشی صنعتی جدید، تغییر خواسته‌های مشتریان و عدم سنجیده شدن سیاست ابلاغ شده و ... صورت گیرد

یک مخزن قابل جستجو و مشاهده سیاست‌های خود بالا بیاورید و همچنین برای خدمات خود و توضیح مختصر آن تا بتوانید سریعا به اطلاعاتی در مورد آنها دست پیدا کنید




به انتهای کتاب حکمرانی soa رسیدیم ، سیاست‌های آنرا مطالعه و جامعیت عملکردی آن را فهمیدیم، اکنون با دانش به این مسائل و موضوعات درک بهتر و پایه مقدماتی رو برای معماری‌های جدیدی از قبیل microservice, DDD و .... و همچنین آمادگی اولیه برای زبان مدلسازی BPM را داریم

#microservice
#soa

@code_crafters

فایل صوتی گپ امشب سعید جان با مشارکت و گفتگوی اعضا عزیز، درباره راه و روش های تشخیص، ذخیره و پردازش بازدید های کاربران از محتوا ها (پست ها، فایل ها، مدیا ها) در مقیاس اپلیکیشن های بزرگ و تعداد کاربر همزمان بالا بود.

* خلاصه مطالبی که در این میت مورد بحث قرار گرفت:
گفتیم با چه روش هایی میتوانیم بازدید هر کاربر از محتواها را بصورت یکتا (هر کاربر یک view برای هر محتوا)،
بدون کاهش پرفورمنس و افزایش زمان‌ ریسپانس ها،
با کمترین فشار به دیتابیس ها و بهترین بازدهی،
و با گارانتی معتبر بودن بازدید ها، ثبت و رصد کنیم.

تکنولوژی‌ و ابزار های بحث شده:
- RabbitMQ Message BUS
- Redis distributed caching
- Background Job Services and Queues
- Databases and storages differences


@code_crafters

زبان های معروف بلاکچین
خب تو این پست قراره با زبان های برنامه نویسی که در بلاکچین کاربرد زیادی داشتند و دارند اشنا بشیم و همچنین در پست بعدی مریم سراغ پیاده سازی بلاکچین و الگورتیم های مربوطه با پایتون🥸🥸
برای توسعه‌ی بلاک چین زبان‌های مختلفی وجود دارند، اما برخی محبوب‌تر و برخی‌ دیگر ناشناخته‌تر باقی‌مانده‌اند.

1-سی پلاس پلاس (C++)

C++ یک زبان برنامه نویسی شی‌گرا است که در فناوری بلاک چین برای اولین بار توسط بنیان‌گذاران بیت کوین استفاده شد

2-سالیدیتی (Solidity)

این زبان برنامه نویسی بلاکچین توسط اتریوم توسعه داده شد و هدف اصلی آن کمک به توسعه‌دهندگان برای ایجاد شبکه‌های بلاک چین بر روی پلتفرم خود بود. از آنجایی‌که Solidity به توسعه‌دهندگان بلاک چین اختصاص داده شده است
از Solidity می‌توان برای ایجاد قراردادهای هوشمند جهت رای دادن، تامین مالی جمعی و کیف پول‌های چند امضایی استفاده کرد. همچنین این زبان برنامه نویسی بلاکچین یکی از سریع‌ترین‌های حوزه‌ی خود شناخته می‌شود.

3-پایتون (Python)

برای تازه‌کارهای در حوزه‌ی زبان برنامه نویسی بلاکچین، پایتون یکی از انتخاب‌های عالی محسوب می‌شود. البته بسیاری معتقدند زبان پایتون حتی از سی پلاس پلاس هم مناسب‌تر و بهتر است. به‌عنوان یک توسعه‌دهنده مبتدی، می‌توانید از پایتون برای ایجاد نمونه‌های اولیه بدون نیاز به کدهای طولانی استفاده کنید
تنها یک مشکل به پایتون، این زبان برنامه نویسی بلاکچین وارد بوده که آن هم مفسری بودن این زبان است. این موضوع مشکلاتی برای عملیات رمزنگاری پیچیده در بلاک چین ایجاد می‌کند.

4-وایپر (Vyper)

زبان برنامه نویسی وایپر یکی تازه نفس‌ها در زمینه‌ی توسعه‌ بلاک چین به حساب می‌آید که از پایتون ۳ مشتق شده است. با اینکه Vyper تمام ویژگی‌های پایتون را ندارد، به‌عنوان جایگزینی برای Solidity ساخته می‌شود. از این زبان برنامه نویسی بلاکچین معمولاً مانند Solidity برای ماشین مجازی اتریوم (EVM) استفاده می‌شود. با این حال، Vyper ساختارهای کنترلی متفاوتی نسبت به Solidity دارد و همچنین مسائل امنیتی را به طور متفاوتی مدیریت می‌کند.
اگر یک زبان توسعه بلاک چین برای نوشتن قراردادهای هوشمند می خواهید، وایپر را نیز در لیست برترین‌های زبان برنامه نویسی بلاکچین قرار دهید.

5-جاوا (Java)

جاوا از نظر محبوبیت و مزایا، رقابت سختی را با C++ ایجاد کرده است که در فناوری بلاک چین نیز این رقابت دیده می‌شود.
برنامه‌های جاوا را می‌توان بر روی پلتفرم‌های مختلف اجرا کرد چرا که از ویژگی عملکرد WORA به معنای یک بار بنویس، در هر جایی اجرا کن (Write once, run anywhere) برخوردار است. از طرفی، این برنامه‌ها به معماری
خاص سیستم وابسته نیستند؛ زیرا از JVM جهانی (ماشین مجازی جاوا) برای اجرا استفاده می‌کنند. همین ویژگی کافیست تا توسعه‌دهندگان، جاوا را یک زبان برنامه نویسی بلاکچین بی‌نظیر بدانند.

6-گولنگ (Golang)

گو یا گولنگ یکی دیگر از زبان‌های برنامه‌نویسی است که به‌راحتی می‌توان از آن برای توسعه بلاک چین استفاده کرد. GO توسط تیم گوگل توسعه داده شده است و در درجه اول برای ساخت سیستم‌های غیرمتمرکز کاربرد دارد. علت اصلی استفاده‌ی توسعه‌دهندگان از GO سادگی و سهولت مقیاس‌پذیری آن است.
از آنجایی‌که زبان برنامه نویسی Go به صورت ایستا تایپ شده و یک زبان برنامه نویسی کامپایل شده است، برای برنامه نویسی بلاک چین عالی است.

سایر زبان‌های برنامه‌نویسی بلاکچین:
(C#)
(Java Script)
(Simplicity)
(Rholang)
(PHP)
(Ruby)
(Rust)
(Erlang)
(CX)
#blockchain
#web3
@code_crafters

در دنیای توسعه نرم افزار برای کسب و کارهای تجاری چه میگذرد؟؟؟


بیایید با یک تشریح پیش برویم، تصور کنید شما مدیر فنی یک سازمان در توسعه نرم افزار هستید، یک کمپانی یا یک شرکت دارای تجارت از سازمان شما خواسته که یک نرم افزار جامع براشون طراحی کنید و خب شما بعنوان یک مدیرفنی در سازمانتون این ماموریت رو برعهده دارید که این امر رو محقق کنید، علاوه بر این ممکن است یک سازمان از شما بخواهد بعنوان مشاور فنی مدت معینی رو در این سازمان حضور پیدا کرده و برای آنها یک راه حل نرم افزاری ارائه دهید، اینجاست که پای معماری‌های بزرگ و مشهور امروزی به میان کشیده میشه و به شما در تحقق این مسئله کمک خواهد کرد
DDD (domain-driven design)
طراحی دامنه محور

شما مسئول شده‌اید که یک راه حل ارائه بدهید که خلاقیت در آن نیز دیده شود و قبل از آن نیاز دارید که مشکل را درک کنید و دامنه تجاری این کسب و کار رو شناسایی کنید

در سلسله مراتب مربوط به این پست در این خصوص باهم حرف میزنیم


تحلیل دامنه‌های تجاری

شاید این سوال مطرح شود که ما میخواهیم یک نرم افزار توسعه دهیم،نه راه اندازی یک کسب و کار، آیا دانش و درک این مطالب اهمیت دارد؟؟؟جواب شما یک بله قاطعانه است، شما باید بدانید چرا شرکتها وجود دارند، چه اهدافی را دنبال میکنند و استراتژی آنها برای دست یافتن به اهدافشان چیست، شما باید زمینه را درک کنید تا مشکل را بفهمید، زمینه‌ای که کسب و کار در آن وجود دارد، یعنی استراتژی کسب و کار سازمان، و ارزشی که با ساخت نرم افزار به آن داده میشود، شما با حضور مداوم در سازمان ثانویه شروع میکنید به تجزیه و تحلیل دامنه تجاری شرکت و ساختار آن را خواهید آموخت: زیر دامنه‌های اصلی ،پشتیبانی و بخش عمومی آن و این زمینه ساز طراحی نرم افزار است

دامنه تجاری business domain چیست؟
دامنه تجاری حوزه اصلی فعالیت یک شرکت هستش، بطور کلی خدماتی هستش که به مشتریان ارائه میدهد، برای مثال:
-استارباکس بخاطر قهوه‌ش شناخته میشود
وال‌مارت بزرگترین شرکت خرده فروشی می‌باشد

بعضی شرکت‌ها ممکن است چند دامنه تجاری داشته باشند برای مثال شرکت آمازون که در دو حوزه خرده فروشی و فراهم کردن زیرساخت ابری فعالیت دارد، این نکته قابل توجه است که برخی کمپانی‌ها ممکن است دامنه تجاری خودشون رو تغییر بدن برای مثال شرکت نوکیا که در حوزه‌های، تهیه چوب، مخابرات و ارتباطات و لاستیک فعالیت کرده است

زیر دامنه subdomain چیست؟؟
برای دستیابی به اهداف حوزه تجاری، یک شرکت باید در چندین زیر دامنه فعالیت کند، زیر دامنه یک حوزه ریز از فعالیت تجاری هستش، همه زیر دامنه‌های یک شرکت دامنه تجاری اون رو تشکیل میدهند، پیاده سازی یک زیر دامنه برای موفقیت یک شرکت کافی نیست. این فقط یک بلوک از ساختمان تجاری میباشد، زیر دامنه‌ها باید باهم دیگه ارتباط داشته باشن(این مسئله یکی از موضوعات زیربنایی طراحی نرم افزار برای یک شرکت تجاری هستش، شما باید درکی از چگونگی ارتباط بخش‌ها باهمدیگه رو داشته باشید و تفکیک دسترسی تا سطح مورد نیاز رو برای هر بخش در نرم افزارتون فراهم کنید)

برای مثال استارباکس باید املاک و مستغلات رو در مکانهای موثر بخرد و اجاره کند، پرسنل استخدام کند و امور مالی رو اداره کند، هیچ یک از این زیر دامنه ها به تنهایی یک شرکت سودآور رو ایجاد نمیکند، اما همه این موارد برای یک شرکت کن بتواند در حوزه تجاری خود رقابت کند ضروری است


انواع زیردامنه‌ها
همانطور که یک برنامه نرم افزاری شامل انواع مختلفی از معماری، پایگاه داده‌ها و قسمت فرانتی و سرویس‌های بکندی و ... میباشد، زیردامنه‌ها شامل ارزش استراتژیکی/تجاری متفاوتی هستند، طراحی دامنه محور بین سه نوع دامنه تمایز قائل میشود:هسته، عمومی، پشتیبانی.

بیایید ببینیم آنها چگونه از دیدگاه استراتژی شرکت متفاوت هستند

زیر دامنه اصلی:
کاری است که یک شرکت متفاوت از رقبای خود انجام می‌دهد، این ممکن است شامل اختراع محصولات یا خدمات جدید یا کاهش هزینه‌های با بهینه سازی فرآیندهای موجود باشد. برای مثال شرکت اوبر رو در نظر بگیرید که شکل جدیدی از حمل و نقل رو ارائه کرد:اشتراک سواری، زمانیکه رقبای خود رو دید راه‌هایی برای بهینه سازی و تکامل کسب و کار اصلی خود پیدا کرد:کاهش هزینه با هماهنگ کردن سوارکارانی که در همان جهت حرکت می‌کنند

زیردامنه‌های اصلی، بر نتایج نهایی شرکت تاثیر میگذارد. به این ترتیب این شرکت خود را از رقبا خود متمایز میکند. این استراتژی شرکت برای ارائه خدمات بهتر به مشتریان و/یا به حداکثر رساندن سود آن است. برای حفظمزیت رقابتی، زیر دامنه های اصلی شامل اختراعات، بهینه سازی هوشمند، دانش کسب و کار یا سایر مالکیت‌های معنوی است


#DDD
#domain_driven_design

@code_crafters

این سوال مطرح میشود که زیردامنه اصلی رو چگونه تشخیص دهیم؟؟؟
اگر اون بخش و فعالیت، ارتباط مستقیمی با درآمد سازمان داشته باشد یا یک مزیت رقابتی باشد، زیردامنه اصلی محسوب میشود، برای مثال: جستجوی گوگل یک سرویس رایگان است که در هدایت و تقسیم بار شبکه تاثیر مستقیمی دارد و الگوریتم جستجوی گوگل در آن بشدت تاثیر گذار است که اگر رقبای گوگل در این بخش بهتر فعالیت کنند، تاثیر چشم گیری بر فعالیت گوگل و درآمد تبلیغاتی آن خواهد گذاشت، بنابراین الگوریتم جستجوی گوگل یک زیردامنه اصلی محسوب میشود


پیچیدگی:
یک زیردامنه اصلی که پیاده سازی آن ساده است، میتواند یک مزیت رقابتی کوتاه مدت ایجاد کند، بنابراین زیردامنه‌های اصلی بطور طبیعی پیچیده هستند. برای مثال: شرکت اوبر بعد از دهه‌ها با ارائه یک راهکار جدید با استفاده از فناوری‌های نوین ،دهه‌ها صنعت حمل و نقل سنتی رو متحول کرد، اوبر توانست روش قابل اعتمادتر و شفافتری برای حمل و نقل طراحی کند، برای کسب و کار اصلی یک شرکت باید موانع زیادی برای ورود وجود داشته باشد و کپی کردن یا تقلید از راه حل شرکت برای رقبا باید سخت باشد

منابع مزیت رقابتی:
زیردامنه‌های اصلی لزوما فنی نیستند. همه مشکلات تجاری از طریق الگوریتم‌ها یا راه حل‌های فنی دیگر حل نمیشوند، مزیت رقابتی میتواند از منابع مختلفی حاصل شود.
بعنوان مثال: یک جواهرساز محصولات خود را بصورت آنلاین می‌فروشد، فروشگاه آنلاین مهم است اما زیردامنه اصلی نیست، طراحی جواهرات زیر دامنه اصلی محسوب می‌شود. این شرکت می‌تواند از موتور فروشگاه آنلاین استفاده کند اما نمی‌تواند طراحی جواهرات خود را برون سپاری کند، این طراحی دلیلی است که مشتریان محصولات سازنده جواهرات رو می‌خرند و برند رو به یاد می آورند

زیر دامنه اصلی همان دامنه اصلی هستش ، به اون زیردامنه میگوییم چون ممکن در طول زمان یک زیردامنه اصلی به زیردامنه عمومی تغییر کند

زیردامنه‌های عمومی:
زیردامنه‌های عمومی فعالیت‌های تجاری هستند که همه شرکت‌ها به یک شکل انجام میدهند و پیچیدگی زیردامنه‌های اصلی رو داره ،پیاده سازی آن دشواره و هیچ مزیت رقابتی نداره، نیازی به نوآوری و بهینه سازی نیست، برای مثال: سیستم احراز هویت و مجوزدهی، یا اگر به مثال قبلی برگردیم ،جواهر سازی فروشگاه آنلاین یک زیردامنه عمومی هستش که مزیت رقابت ایجاد نمیکند

زیردامنه پشتیبانی:
از زیردامنه‌های شرکت پشتیبانی میکنند و هیچ مزیتی برای رقابت ایجاد نمیکنند برای مثال: در یک شرکت تبلیغاتی زیردامنه‌های اصلی شامل تطبیق تبلیغات با بازدیدکنندگان، بهینه سازی تبلیغات و کاهش هزینه‌هاست، که شرکت باید در آن خلاقانه عمل کند مانند بنرها و تجزیه و تحلیل کاتالوگ‌ها که تاثیری بر سود آن ندارد، چیزی برای اختراع یا بهینه سازی در آن زمینه وجود ندارد، تمایز اصلی بین پشتیبانی از زیردامنه‌های اصلی پیچیدگی منطق تجاری راه حل است، در سیستم‌های نرم افزاری هرآنچه CRUD باشد که هیچ مزیت رقابتی ایجاد نمیکند

مقایسه زیردامنه‌ها:
اکنون که با سه زیردامنه عمومی آشنا شدید بهتر میتوانید انها را درک کنید
۱-مزیت رقابتی:

زیردامنه اصلی یک مزیت رقابتی است و استراتژی اصلی برای ایجاد تمایز بین رقبا

زیردامنه عمومی هیچگونه مزیت رقابتی ندارد و تمامی شرکت‌ها از آن بهره میبرند

زیر دامنه پشتیبانی موانع کمی دارد و مزیت رقابتی ندارد و شرکت‌ها بدشون نمیاد از راه‌حل‌های عمومی و اماده استفاده کنند که منجر به کاهش هزینه‌ها شود

هرچه یک شرکت بتواند با مشکلاتی پیچیده‌تر مقابله کند، ارزش تجاری بیشتری میتواند ارائه دهد برای مثال: یک مشکل پیچیده میتواند بهینه سازی و کارآمدتر کردن کسب و کار باشد، ارائه خدمات مشابه رقبا با هزینه عملیاتی کمتر، یک مزیت رقابتی نیز محسوب میشود

۲-پیچیدگی:
زیردامنه‌های مختلف، پیچیدگی‌های سطوحی مختلفی ایجاد میکنند، از منظر فنی‌تر شناسایی زیردامنه‌های سازمام مهم است، هنگام طراحی نرم افزار، ما باید ابزارها و تکنیک‌هایی را انتخاب کنیم که با زیردامنه‌ها سازگاری داشته باشد

منطق تجاری زیردامنه‌های پشتیبانی ساده است معمولا اینها از سطح CRUD فراتر نمیروند

زیردامنه‌های عمومی پیچیده‌تر هستند و دلیل خاصی دارد که چرا قبلا صرف زمان و تلاش برای آن صورت گرفته است مانند الگوریتم‌های رمزگذاری یا مکانیسم احرازهویت

از منظر دانش،زیردامنه‌های عمومی ناشناخته‌های شناخته شده هستند همون چیزهایی که میدانید که نمیدانید(نمیدونم چرا نویسنده یهو فاز افلاطون گرفت😅😅😅) میتوانید از بهترین شیوه‌های موجود در بازار استفاده کنید یا یک مشاور متخصص در این زمینه برای کمک به طراحی راه حل سفارشی استخدام کنید(این نکته من رو به یاد بحث sso در سیاست‌های حکمرانی soa انداخت به هر حال درک مطالب این حوزه نیاز به دانش soa و میکروسرویسی می‌باشد)

#DDD
#domain_driven_design

@code_crafters

زیر دامنه های اصلی پیچیده هستند.کپی کردن آنها باید برای رقبا سخت باشد، سودآوری شرکت به آن بستگی دارد. به همین دلیل است که از نظر استراتژیک، شرکت ها به دنبال حل مشکلات پیچیده به عنوان زیردامنه اصلی خود هستند

تمایز بین زیردامنه‌ها اغلب چالش برانگیز است، برای پشتیبانی و دامنه اصلی پیچیدگی یک راهنمای مفید است، بپرسید آیا میتوان از زیر دامنه مورد نظر رو به یک تجارت جانبی تبدیل کرد یا خیر، آیا کسی هزینه آنرا به تنهایی پرداخت میکند؟اگر چنین است یک زیردامنه اصلی است. برای تمایز پشتیبانی از عمومی از خود بپرسید نوشتن کد خود ارزانتر و ساده تر از اذغام یک پلتفرم خارجیست، اگر چنین باشد یک زیردامنه پشتیبانیست

از دیدگاه فنی شناسایی زیردامنه‌های اصلی که پیچیدگب آنها بر طراحی تاثیر میگذارد مهم است، یک زیردامنه اصلی لزوما به نرم افزار مربوط نمی‌شود، یکی دیگر از اصول راهنمای مفید جهت شناسایی زیردامنه اصلی مرتبط با نرم افزار، پیچیدگی منطق تجاری است، آیا منطق کسب و کار شبیه رابط CRUD است یا باید از الگوریتم‌ها پیچیده یا فرآیندهای کسب و کار را که توسط قوانین پیچیده کسب و کار و تغییرات ثابت تنظیم شده‌اند، پیاده سازی کنید؟؟؟ در مورد اول زیردامنه پشتیبانی و دومی یک زیر دامنه اصلی است

نوسانات:
زیردامنه‌های اصلی ممکن است تغییر کنند، اگر مشکلی را بتوان در اولین تلاش حل کرد احتمالا مزیت رقابتی نخواهد داشت، در نتیجه راه حل‌هایی برای زیردامنه‌های اصلی پدیدار میشوند، شرکت‌ها بطور مداوم زیردامنه‌های اصلی را نواوری یا تکامل میدهند(افزودن ویژگی‌های جدید یا بهینه کردن عملکرد موجود)به هر حال این رویکرد برای شرکت‌ها ضروری است

زیردامنه‌های پشتیبانی اغلب تغییر نمیکنند و تلاشی که برای زیردامنه‌های پشتیبانی در مقایسه با تلاشی که در یک زیردامنه اصلی سرمایه گذاری شده است ارزش تجاری ناچیزی بوجود می‌آورد

زیردامنه‌های عمومی میتوانند تغییر کنند، این تغییرات به شکل وصله‌های امنیتی، رفع اشکال یا راه حل‌های کاملا جدیدب برای مشکلات عمومی باشد


راه حل‌های استراتژی:
زیردامنه‌های اصلی بخش مهم یک شرکت هستند که به شرکت‌ها این فرصت رو میده تا در صنعت به رقابت بپردازند، اما این به این معنا نیست که دیگر زیردامنه‌ها اهمیت ندارند، زیردامنه‌ها مانند بلوک‌های ساختمانی هستند که در کنار هم چیده میشوند، زیردامنه‌های اصلی را نمیتوان برون سپاری کرد و اگر تکامل آن متوقف گردد مزیت رقابتی رو نسبت به شرکتهای رقیب از دست خواهید داد، ماهرترین نفرات و جدیدترین تکنولوژی‌های مهندسی در خدمت به زیردامنه اصلی هستند

از آنجاکه زیردامنه‌های عمومی مشکلاتی سخت رو حل میکنند، اما خرید انها از بیرون مقرون بصرفه تر از ساخت در داخل هستش

فقدان مزیت رقابتی زیردامنه‌های پشتیبانی، امر نادیده گرفتنسون رو بوجود آورده و چون الزاما هیچگونه مشکل خاصی رو حل نمیکنند پیاده سازی درون سازمانی آن بهتر است، و چون چیزی جز یک منطق تجاری ساده نیست نیازی به نیروی مجرب و تکنولوژی نوین نیست، از دیدگاه همگانی بهترین بخش برای آموزش نیرو‌های مبتدی می‌باشد


شناسایی مرزهای زیردامنه‌ها:

زیردامنه‌های اصلی، استراتژی‌هایی هستند که یک شرکت رو نسبت به رقبای خود متمایز میکند، اگر مدیر شرکت بپرسید زیردامنه‌های شما چیست یک نگاه خالی دریافت خواهید کرد، این وظیفه شماست که انها را شناسایی کنید و گاها مشخص کردن مرزهای آن کار راحتی نیست.

یک نقطه شروع خوب، بخش های شرکت و سایر واحدهای سازمانی است (شما با حضور در شرکت و ارتباط گرفتن با واحدهای مختلف آن شروع به کسب اطلاعاتی میکنید تا از طریق آنها بتوانید زسردامنه‌ها تشخیص و تحزیه و تحلیل کنید)

تقطیر زیردامنه‌ها:
یک فروشگاه رو در نظر بگیرید بخش پشتیبانی فروش آن یک زیردامنه درشت دانه هستش که شامل دانه بندی‌های مختلف و ریزی میگردد، اگر شرکت در یکی از این دانه بندی‌ها الکوریتمی استفاده کرده باشد که مزیت رقابتی ایجاد میکند(مسیریابی ارسال سریع به کاربر و ایجاد حس خوب در مشتریان) این بخش الگوریتم زیردامنه اصلی محسوب میشود، اکثر دانه بندی‌های ریز جز زیردامنه اصلی محسوب میشوند اما جستجوی ما تا کجا باید ادامه یابد؟؟؟ تا جایی که دیگر جستجوهای ما مزیتی ایجاد نکند نقطه خوب برای توقف جهت یافتن زیردامنه اصلی است (در بخش حکمرانی soa راجب درشت دانه‌ها و ریزدانه‌ها قوانینی مطرح شده و نحوه شناسایی آنها نیز) یافتن زیر دامنه‌ها به ما در تحلیل و بررسی دقیق رویکرد نرم افزاری و بهش‌های آن کمک میکند، از دیدگاه فنی تمامی زیردامنه‌ها یک کل منسجم و منبسط هستند که در نهایت بر روی یکسری اطلاعات تغییراتی بوجود می‌آورند

در برخی سازمانها شما با زیردامنه‌هایی مواجه میشوید که ارتباطی با بخش نرم افزار ندارند ،آنها را نادیده گرفته و بر روی موارد دیگر متمرکز شوید

#DDD
#domain_driven_design

@code_crafters