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


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


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

@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

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


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

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

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


کشف دانش:
ارائه یک راه حل نرم افزاری نیازمند پایه‌ای ترین دانش از دامنه تجاری دارد، این دانش متعلق به متخصصان حوزه 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