چهل نکته درباره 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

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


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

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

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


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

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

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

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

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

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

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

زبان فراگیر چیست؟
ایده طراحی دامنه محور ساده است، اگر نیازمند ارتباط هستیم بجای ترجمه باید از یک زبان فراگیر استفاده کنیم

چرخه عمر توسعه نرم افزار سنتی بشکل زیر ترجمه میگردد:
• دانش دامنه به یک مدل تجزیه و تحلیل
• مدل تجزیه و تحلیل به الزامات
• الزامات در طراحی سیستم
• طراحی سیستم به منبع

بجای استفاده از ترجمه به روش سنتی در طراحی دامنه محور نیاز به پرورش یک زبان واحد داریم زبانی که در همه جا حاضر باشد


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

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

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

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

#DDD
#domain_driven_design

@code_crafters

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

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

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

مدل یک کپی از دنیای واقعی نیست، بلکه یک ساختار انسانی است که به ما کمک می کند تا سیستم های دنیای واقعی را درک کنیم.

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

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

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

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

از یک ویکی برای اصطلاحات واژه زبان فراگیر استفاده کنید، اینگونه با افزودن افراد راحتتر خواهد بود، بروزرسانی مداوم این واژه نامه کار همگانی است، برای ضبط زبان میتوانید تست‌های نوشته شده از زبان cherking استفاده کنید تا شکاف بین متخصصان حوزه و مهندسان پر شود:

SCENARIO: Notify the agent about a new support case

         GIVEN Vincent Jules submits a new support case saying:
          """  
          I need help configuring AWS Infinidash
          """  

         WHEN the ticket is assigned to Mr. Wolf  
         
         THEN the agent receives a notification about the new ticket

میتوانید از NDepend برای تایید زبان فراگیر در کدهای خود استفاده کنید


این نیاز به تلاش همگانی دارد

به نقل قول از مانیفست اجایل

افراد و تعاملات بر روی فرآیندها و ابزارها

#DDD
#domain_driven_design

@code_crafters

مدیریت پیچیدگی دامنه

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


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

تا اینجای کار ما دو راه حل داریم اول اینکه پیچیدگی ERD که نارکارآمد است(پیچیدگی بخش همیشگی در کار است و همه جا دیده میشود) دوم استفاده از پیشوند(سرنخ فروش و سرنخ بازاریابی) که این دو مشکل بزرگ در کد ایجاد میکند یک: ناسازگاری با زبان فراگیر، دو:هر کدام رو در کجا استفاده کنیم، هرچقدر دو مدل به همدیگر نزدیکتر باشند احتمال خطا بیشتر است

بیایید با استفاده از طراحی دامنه محور با این سناریو مقابله کنیم:الگوی بافت محور

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

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

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

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

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

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

محدوده یک بافت محدود:
مثال sales یک مرز ذاتی حوزه کسب و کار را نشان داد. کارشناسان حوزه‌های مختلف، مدل‌های ذهنی متناقضی را از یک واحد تجاری ارائه کردند. برای مدل‌سازی حوزه کسب‌وکار، باید مدل را تقسیم می‌کردیم و یک زمینه کاربردی دقیق برای هر مدل ریزدانه (بافت محدود آن) تعریف می‌کردیم.

#DDD
#domain_driven_design

@code_crafters

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

تعریف دامنه یک زبان فراگیر (بافت محدود آن)یک تصمیم طراحی استراتژیک است. مرزها می‌توانند گسترده باشند، با پیروی از حوزه ذاتی کسب‌وکار که زمینه (محدوده) بیشتر حوزه کسب و کار را به حوزه های مشکل کوچکتر تقسیم می کند

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

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

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

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

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

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

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

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


#DDD
#domain_driven_design

@code_craftets

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

مرزهای فیزیکی:
بافت‌های محدود نه تنها به عنوان مرزهای مدل بلکه به عنوان مرزهای فیزیکی سیستم هایی که آنها را اجرا می کنند نیز عمل می کنند. هر بافت محدود باید به عنوان یک سرویس/پروژه فردی پیاده‌سازی شود، به این معنی که مستقل از سایر بافت‌های محدود پیاده‌سازی، تکامل و نسخه‌بندی می‌شود (soa, microservice)

مرزهای فیزیکی واضح بین بافت‌های محدود به ما این امکان را می‌دهد که هر بافت محدود را با پشته فناوری که به بهترین وجه با نیازهای آن مطابقت دارد، پیاده‌سازی کنیم(یکی از مفاهیم میکروسرویس)

یک بافت محدود می تواند شامل چندین زیر دامنه باشد. در چنین حالتی، بافت محدود یک مرز فیزیکی است، در حالی که هر یک از زیر دامنه های آن یک مرز منطقی است. مرزهای منطقی در زبان های برنامه نویسی مختلف نام های مختلفی دارند:فضاهای نام، ماژول ها یا بسته ها

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

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

#DDD
#domain_driven_design

@code_crafters

با تشکر از اعضای گروه (جناب امیر) بابت ترجمه و تهیه این سند

@code_crafters

یکپارچه سازی بافت محدود

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

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

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

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

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

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

هسته مشترک:
بافت‌های محدود مرز مدل‌ها رو مشخص میکنند، اما ممکن است مواردی رخ دهد که همان مدل زیردامنه یا بخشی ازون در کرانهای چندگانه پیاده سازی شود(مدل مشترک بر اساس نیازهای همه بافت‌های محدود طراحی شده است) مدل مشترک باید در تمام بافت‌های محدودی که از آن استفاده میکنند سازگار باشد(نمونه آن مدل authorization است)

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

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

#DDD
#domain_driven_design

@code_crafters

مشتری – تامین کننده:
دومین گروه از الگوهای همکاری که بررسی خواهیم کرد، الگوهای مشتری – تامین کننده است. یکی از بافت‌های محدود - تامین کننده - خدماتی را برای مشتریان خود ارائه می دهد.
ارائه‌دهنده خدمات «بالادست» و مشتری یا مصرف‌کننده «پایین دست» است.
بر خلاف مورد همکاری، هر دو تیم (بالا دستی و پایین دستی) می توانند به طور مستقل موفق شوند. در نتیجه، در بیشتر موارد ما یک عدم تعادل قدرت داریم: تیم بالادستی یا پایین دستی می توانند قرارداد ادغام را دیکته کنند.
این بخش سه الگو را مورد بحث قرار می‌دهد که به چنین تفاوت‌های قدرتی می‌پردازد: الگوهای سازگاری، لایه ضدفساد و الگوهای خدمات میزبان باز.

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

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

لایه ضد فساد(ACL):
همانطور که در الگوی انطباق گرایانه، توازن قدرت در این رابطه همچنان به سمت خدمات بالادستی منحرف است. با این حال، در این مورد، بافت محدود پایین دست مایل به انطباق نیست. می تواند مدل بافت محدود بالادستی را به مدلی متناسب با نیازهای خود از طریق یک لایه ضد فساد ترجمه کند.

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

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

سرویس میزبان باز(Open-Host Service):
این دقیقا نقطه متقابل لایه ضد فساد است و تامین کننده(سرویس بالادستی-بیرونی-) از مصرف کنندگان حمایت میکند و خروجی را مطابق میل انها ارائه میدهد این ملزم به نوشتن لایه‌هایی مختلفی است که زیان مصرف کنندگان رو تامین کند و خروجی کطابق زبان انها ارائه دهد

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

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

برای ترسیم نقشه از برنامه context mapper استفاده کنید

#DDD
#domain_driven_design

@code_crsfters

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

اولین چیزی که نیاز داریم یه کلاس تراکنش هست که یه سری مشخصات رو مثل فرستنده , گیرنده , محصول و مقدار اون محصول رو دریافت کنیم

import hashlib
import time

class Transaction:
    def __init__(self, sender, recipient, product, quantity):
        self.sender = sender
        self.recipient = recipient
        self.product = product
        self.quantity = quantity

    def __str__(self):
        return f"Transaction(sender: {self.sender}, recipient: {self.recipient}, product: {self.product}, quantity: {self.quantity})"

حالا که تراکنش‌ها رو تعریف کردیم، باید یک کلاس برای بلاک‌ها ایجاد کنیم. هر بلاک در زنجیره شامل چند ویژگی اصلی که به ترتیب عبارتند از:
شماره بلاک در زنجیره (index)
هش بلاک قبلی در زنجیره (previous_hash)
زمان ایجاد بلاک (timestamp)
لیست تراکنش‌های درون بلاک (transactions)
عددی که برای ماینینگ استفاده میشه (nonce)
هش بلاک (hash):که با استفاده از تراکنش‌ها و ویژگی‌های دیگر بلاک ساخته میشه

class Block:
    def __init__(self, index, previous_hash, timestamp, transactions, nonce=0):
        self.index = index
        self.previous_hash = previous_hash
        self.timestamp = timestamp
        self.transactions = transactions
        self.nonce = nonce
        self.hash = self.calculate_hash()

    def calculate_hash(self):
        transactions_string = ""
        for tx in self.transactions:
            transactions_string += str(tx)

        block_string = f"{self.index}{self.previous_hash}{self.timestamp}{transactions_string}{self.nonce}"
        return hashlib.sha256(block_string.encode()).hexdigest()

    def __str__(self):
        return f"Block<index: {self.index}, hash: {self.hash}>"

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

class Blockchain:
    difficulty = 4  # میزان سختی برای ماینینگ بلاک

    def __init__(self):
        self.chain = [self.create_genesis_block()]
        self.pending_transactions = []

    def create_genesis_block(self):
        # genesis block  ایجاد بلاک اول با متود
        return Block(0, "0", time.time(), [])

    def get_latest_block(self):
        #A: دریافت آخرین بلاک در زنجیره
        return self.chain[-1]

    def add_transaction(self, transaction):
        #B: اضافه کردن تراکنش به لیست تراکنش‌های معلق یا در تایید انتظار
        self.pending_transactions.append(transaction)

    def mine_pending_transactions(self):
        #C: ماین کردن تراکنش‌های معلق و اضافه کردن بلاک به زنجیره
        block = Block(len(self.chain), self.get_latest_block().hash, time.time(), self.pending_transactions)
        self.mine_block(block)
        self.chain.append(block)
        self.pending_transactions = []

    def mine_block(self, block):
        #D: Proof of Work ماین کردن یک بلاک با استفاده از الگوریتم 
        while block.hash[:self.difficulty] != "0" * self.difficulty:
            block.nonce += 1
            block.hash = block.calculate_hash()
        print(f"Block mined: {block.hash}")

    def is_chain_valid(self):
       #E: بررسی اعتبار کل زنجیره با مقایسه هش‌ها و هش‌های محاسبه شده
        for i in range(1, len(self.chain)):
            current_block = self.chain[i]
            previous_block = self.chain[i - 1]

            if current_block.hash != current_block.calculate_hash():
                return False

            if current_block.previous_hash != previous_block.hash:
                return False

        return True

ادامه توضیحات کلس BlockChain و نحوه ساخت یه بلاک با تراکنش هاش تو پست بعدی🥸
#blockchain

ساخت بلاک های اولیه و تراکنش
خب در نهایت به این میرسیم که چطوری میتونیم از کلس هامون استفاده کنیم

blockchain = Blockchain()

#A: ایجاد تراکنش‌
blockchain.add_transaction(Transaction('Farm', 'Warehouse', 'Tomatoes', 70))
blockchain.add_transaction(Transaction('Warehouse', 'Distributor', 'Tomatoes', 90))
blockchain.add_transaction(Transaction('Distributor', 'Retailer', 'Tomatoes', 80))

#B: ماین کردن تراکنش‌های معلق
blockchain.mine_pending_transactions()

#C: بررسی اعتبار زنجیره
print(f"Blockchain valid: {blockchain.is_chain_valid()}")

#D: نمایش بلاک‌ها و تراکنش‌ها
for block in blockchain.chain:
    print(block)
    for tx in block.transactions:
        print(f"txt = {tx}")

این تیکه کد، یک نمونه ساده از استفاده از کلاس بلاکچین و متود  های اون را نشان می‌ده. در اینجا، یک ابجکت از کلاس Blockchain ایجاد می‌شود و  سه تراکنش برای ردیابی محصولات غذایی  اضافه می‌شه. بعد از اون تراکنش‌های معلق ماین شده و یک بلاک جدید به زنجیره اضافه می‌شود و  اعتبار زنجیره چک می‌شه و در نهایت بلاک‌ها و تراکنش‌ها نمایش داده می‌شود.


پ ن: توضیح عمقی تر درمورد کلاس Blockchain

مورد اول difficulty: این متغییر نشان می‌دهه که برای ماین کردن یک بلاک جدید چه تعداد صفر در ابتدای هش باید وجود داشته باشد.فرض کنید که مقدار difficulty در بلاکچین  برابر 3 باشد.
ب فرض کنیم ما بلاکی را می‌خواهیم ماین کنیم و هش بلاک  باید اینگونه باشد:
hash: 000abc123

دوم ()init: در این متد، زنجیره با ایجاد بلاک اول (genesis block) شروع می‌شود و لیست تراکنش‌های در انتظار برای ماین کردن خالی می‌شود.

سوم:create_genesis_bloc()k: این متد بلاک اول یا genesis block را با شماره بلاک 0، هش بلاک قبلی صفر، زمان فعلی و بدون تراکنش ایجاد می‌کند. معمولا بلاک اول زنجیره رو خوومون درست میکنیم و بدون تراکنش و هش صفر

چهار: get_latest_block(): این متد آخرین بلاک در زنجیره را برمی‌گرداند.

پنج:add_transaction(transaction): این متد یک تراکنش را به لیست تراکنش‌های در انتظار برای ماین کردن اضافه می‌کند.

شش:mine_pending_transactions: این متد تمام تراکنش‌های در انتظار را ماین می‌کند و بلاک حاوی آن‌ها را به زنجیره اضافه می‌کند.

هفت:mine_block(block): این متد یک بلاک را با استفاده از الگوریتم Proof of Work ماین می‌کند، تا هش بلاک با تعداد صفرهای مشخص (بر اساس difficulty) شکل بگیرد.

هشت:()is_chain_valid: این متد بررسی می‌کند که زنجیره فعلی اعتبار دارد یا نه، با مقایسه هش‌های بلاک‌ها و هش‌های محاسبه شده.
#blo

#blockchain

@Code_Crafters