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


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

راه‌هایی برای بهینه‌سازی کوئری‌های SQL

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

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

1. کاهش استفاده از کاراکترهای وایلدکارت (wildcard)
استفاده از کاراکترهای وایلدکارت مانند % و _ در کوئری‌های SQL می‌تواند عملکرد کوئری را کند کند. زمانی که از کاراکترهای وایلدکارت استفاده می‌شود، پایگاه داده باید کل جدول را برای یافتن داده‌های مرتبط بررسی کند. برای بهینه‌سازی کوئری‌های SQL، لازم است استفاده از کاراکترهای وایلدکارت را به حداقل برسانیم و تنها در مواقع ضروری از آن‌ها استفاده کنیم.

به عنوان مثال، برای یافتن تمام مشتریانی که نام خانوادگی شهرشان با حرف "P" شروع می‌شود، کوئری زیر استفاده می‌شود:

SELECT * FROM customers WHERE last_name_city LIKE 'P%';

این کوئری کار می‌کند، اما کندتر از کوئری است که از ایندکس (Index) استفاده می‌کند. می‌توان کوئری را با افزودن ایندکس به ستون last_name_city بهبود بخشید و آن را به شکل زیر نوشت:

SELECT * FROM customers WHERE last_name_city >= 'P' AND last_name < 'Q';

این کوئری از ایندکس استفاده می‌کند و سریع‌تر از کوئری قبلی خواهد بود.

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

برای بهبود کوئری‌های SQL، می‌توان ایندکس‌هایی بر روی ستون‌هایی که به طور مکرر در عبارات WHERE، JOIN و ORDER BY استفاده می‌شوند ایجاد کرد. اما ایجاد ایندکس‌های زیاد می‌تواند عملیات اصلاح داده‌ها مانند INSERT، UPDATE و DELETE را کند کند. در انتخاب ستون‌هایی که باید ایندکس شوند و نوع ایندکس‌هایی که باید استفاده شوند، باید تعادلی بین عملکرد خواندن و نوشتن برقرار کرد.

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

SELECT * FROM orders WHERE customer_number = 2154;

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

CREATE INDEX idx_orders_customer_number ON orders (customer_id);

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

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

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

#SQL
@Code_Crafters

4. اجتناب از استفاده از زیرکوئری‌ها (subqueries)
زیرکوئری‌ها می‌توانند عملکرد کوئری را کند کنند، به خصوص زمانی که در عبارات WHERE یا HAVING استفاده می‌شوند. لازم است تا حد ممکن از زیرکوئری‌ها اجتناب شود و از JOIN یا تکنیک‌های دیگر استفاده شود.

به عنوان مثال، برای یافتن تمامی مشتریانی که در 30 روز گذشته سفارشی ثبت کرده‌اند، کوئری زیر از یک زیرکوئری برای یافتن تمامی شناسه‌های سفارش در 30 روز گذشته استفاده می‌کند:

```
SELECT * FROM customers WHERE customer_id IN (SELECT customer_id FROM orders WHERE order_date >= DATEADD(day, -30, GETDATE()));

این کوئری کار می‌کند، اما کندتر از کوئری است که از JOIN برای یافتن داده‌های مرتبط استفاده می‌کند. کوئری زیر از JOIN برای یافتن تمامی مشتریانی که در 30 روز گذشته سفارشی ثبت کرده‌اند استفاده می‌کند:

SELECT DISTINCT c.* FROM customers c JOIN orders o ON c.customer_id = o.customer_id WHERE o.order_date >= DATEADD(day, -30, GETDATE());

این کوئری جدول customers را با جدول orders پیوند می‌دهد و اطلاعات تمامی مشتریانی که در 30 روز گذشته سفارشی ثبت کرده‌اند را بازیابی می‌کند. این کوئری سریع‌تر از کوئری قبلی خواهد بود زیرا از زیرکوئری استفاده نمی‌کند.

5. استفاده از LIMIT یا TOP برای محدود کردن تعداد ردیف‌های بازگشتی
باید از عبارت LIMIT یا TOP برای محدود کردن تعداد ردیف‌های بازگشتی در کوئری‌های SQL استفاده شود. این کار باعث می‌شود داده‌های کمتری پردازش و بازگردانده شود.
(این مورد بستگی به نوع پایگاه داده دارد مثلا SQL Server از Top پشتیبانی میکند در حالی که PostgreSQL و MySQL از Limit پشتیبانی میکنند )
برای مثال، اگر بخواهیم تمامی مشتریانی که در 27 روز گذشته سفارشی ثبت کرده‌اند را پیدا کنیم و تعداد زیادی از مشتریان در این مدت سفارش داده‌اند، کوئری می‌تواند تعداد زیادی ردیف بازگرداند. این کوئری را می‌توان با استفاده از LIMIT یا TOP بهینه کرد. کوئری زیر تعداد ردیف‌های بازگشتی را به 10 محدود می‌کند:

SELECT TOP 10 * FROM customers WHERE customer_id IN (SELECT customer_id FROM orders WHERE order_date >= DATEADD(day, -27, GETDATE()));

این کوئری تنها 10 ردیف اولی که با معیارها مطابقت دارند را بازمی‌گرداند که باعث بهبود عملکرد کوئری خواهد شد.

6. اجتناب از استفاده از SELECT *
استفاده از عبارت SELECT * می‌تواند عملکرد کوئری را کند کند زیرا تمامی ستون‌های یک جدول را بازمی‌گرداند، حتی آن‌هایی که برای کوئری لازم نیستند. برای بهینه‌سازی کوئری‌های SQL، مهم است که تنها ستون‌هایی را که برای کوئری لازم هستند انتخاب کنید.

به عنوان مثال، برای یافتن تمامی مشتریانی که در 30 روز گذشته سفارشی ثبت کرده‌اند، کوئری زیر تمامی ستون‌ها از جدول customers را انتخاب می‌کند:

SELECT * FROM customers WHERE customer_id IN (SELECT customer_id FROM orders WHERE order_date >= DATEADD(day, -30, GETDATE()));

برای بهینه‌سازی این کوئری، می‌توان عبارت SELECT را تغییر داد تا تنها ستون‌های مورد نیاز را انتخاب کند:

SELECT customer_id, first_name, last_name FROM customers WHERE customer_id IN (SELECT customer_id FROM orders WHERE order_date >= DATEADD(day, -30, GETDATE()));

این کوئری تنها ستون‌های customer_id، first_name و last_name را انتخاب می‌کند که عملکرد کوئری را بهبود می‌بخشد.

#SQL
@Code_Crafters

یه مورد دیگه ای هم خودم اضافه کنم که به نظرم لازمه گاهی اوقات لازمه که یک همچنین کوئری بزنید که بررسی کند که یک مقداری وجود دارد یا خیر که در نوشتن پروسیجر ها بسیار مرسوم است:

 
IF EXISTS(SELECT * FROM dbo.Employee AS em WHERE em.Id = 1)
BEGIN 
      PRINT('exist')
      RETURN;
END 
PRINT('not found')

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

 
IF EXISTS(SELECT 1 FROM dbo.Employee AS em WHERE em.Id = 1)
BEGIN 
      PRINT('exist')
      RETURN ;
END 
PRINT('not found')

به جای عملکرد * از عدد یا حروف به شکل 'A' میتوان استفاده کرد که اگر مقداری با شرط ما پیدا کرد را برگرداند که عملکرد بهتری دارد

در این کد بخش های پرینت و شرط و.. T-SQL است و به موضوع پست مربوط نیست تنها قصدم نشان دادن کاربردی تره موضوع بود.

#SQL
@Code_Crafters

7. استفاده از EXISTS به جای IN
عبارت IN یک مقدار را با لیستی از مقادیر بازگشتی از یک زیرکوئری مقایسه می‌کند. با این حال، استفاده از IN می‌تواند عملکرد کوئری را کند کند زیرا نیازمند اسکن کامل جدول بر روی زیرکوئری است. برای بهینه‌سازی کوئری‌های SQL، می‌توان از EXISTS به جای IN استفاده کرد.

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

SELECT * FROM customers WHERE customer_id IN (SELECT customer_id FROM orders WHERE order_date >= DATEADD(day, -30, GETDATE()));

این کوئری از IN برای مقایسه شناسه مشتری با لیست شناسه‌های مشتری بازگشتی از زیرکوئری

استفاده می‌کند. برای بهینه‌سازی کوئری، می‌توان از EXISTS به جای IN استفاده کرد:

SELECT * FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id AND o.order_date >= DATEADD(day, -30, GETDATE()));

این کوئری از EXISTS برای بررسی اینکه آیا ردیف مطابقی در جدول orders وجود دارد یا خیر استفاده می‌کند. این می‌تواند عملکرد کوئری را با اجتناب از اسکن کامل جدول بهبود بخشد.

8. استفاده از GROUP BY برای گروه‌بندی داده‌ها
عبارت GROUP BY برای گروه‌بندی ردیف‌ها بر اساس یک یا چند ستون استفاده می‌شود. این می‌تواند برای خلاصه کردن داده‌ها یا انجام توابع تجمعی بر روی گروه‌های داده مفید باشد. با این حال، استفاده از GROUP BY می‌تواند عملکرد کوئری را کند کند اگر به طور غیرضروری استفاده شود. برای بهینه‌سازی کوئری‌های SQL، باید تنها زمانی که ضروری است از GROUP BY استفاده کرد.

به عنوان مثال، برای یافتن تعداد کل سفارش‌های انجام شده توسط هر مشتری:

SELECT customer_id, COUNT(*) as order_count FROM orders GROUP BY customer_id;

این کوئری از GROUP BY برای گروه‌بندی ردیف‌ها بر اساس شناسه مشتری و شمارش تعداد سفارش‌های انجام شده توسط هر مشتری استفاده می‌کند. برای بهینه‌سازی کوئری، می‌توان از زیرکوئری برای بازیابی اطلاعات مشتری و پیوند آن با جدول orders استفاده کرد:

SELECT c.customer_id, c.first_name, c.last_name, o.order_count FROM customers c JOIN (SELECT customer_id, COUNT(*) as order_count FROM orders GROUP BY customer_id) o ON c.customer_id = o.customer_id;

این کوئری از زیرکوئری برای محاسبه تعداد سفارش‌های انجام شده توسط هر مشتری استفاده می‌کند و سپس نتیجه را با جدول customers برای بازیابی اطلاعات مشتری پیوند می‌دهد. این اجتناب از استفاده از GROUP BY می‌کند و می‌تواند عملکرد کوئری را بهبود بخشد.

9. استفاده از رویه‌های ذخیره‌شده (Stored Procedures)
رویه‌های ذخیره‌شده (Stored Procedures) دستورات SQL پیش‌کامپایل شده‌ای هستند که در پایگاه داده ذخیره می‌شوند. آن‌ها می‌توانند از یک برنامه یا مستقیماً از یک کوئری SQL فراخوانی شوند. استفاده از رویه‌های ذخیره‌شده می‌تواند عملکرد کوئری را با کاهش مقدار داده‌ای که بین پایگاه داده و برنامه ارسال می‌شود و با کاهش زمان لازم برای کامپایل و اجرای دستورات SQL بهبود بخشد.

#SQL
@Code_Crafters

10. بهینه‌سازی طراحی پایگاه داده
بهینه‌سازی طراحی پایگاه داده نیز می‌تواند عملکرد کوئری را بهبود بخشد. این شامل اطمینان از نرمال‌سازی صحیح جداول و استفاده مؤثر از ایندکس‌ها است. علاوه بر این، مهم است که پایگاه داده برای بار کاری مورد انتظار به درستی تنظیم شود و برای سطح مناسب همزمانی (Concurrency) پیکربندی شود.

11. استفاده از ابزارهای بهینه‌سازی کوئری
انواع مختلفی از ابزارهای بهینه‌سازی کوئری موجود هستند که می‌توانند به شناسایی مشکلات عملکرد در کوئری‌های SQL کمک کنند. این ابزارها می‌توانند توصیه‌هایی برای بهبود عملکرد کوئری‌ها ارائه دهند، مانند ایجاد ایندکس‌ها، بازنویسی کوئری‌ها یا بهینه‌سازی طراحی پایگاه داده. برخی از ابزارهای محبوب بهینه‌سازی کوئری شامل Microsoft SQL Server Query Optimizer، Oracle SQL Developer و MySQL Query Optimizer هستند.

12. مانیتورینگ عملکرد کوئری
مانیتورینگ عملکرد کوئری یک گام مهم در بهینه‌سازی کوئری‌های SQL است. با مانیتورینگ عملکرد کوئری، می‌توان مشکلات عملکرد را شناسایی و تنظیمات مناسب را انجام داد. این می‌تواند شامل بهینه‌سازی ایندکس‌ها، بازنویسی کوئری‌ها یا تنظیم طراحی پایگاه داده باشد. برای ردیابی عملکرد کوئری، تعدادی ابزار موجود است، از جمله SQL Server Profiler، Oracle Enterprise Manager و MySQL Enterprise Monitor.

نتیجه‌گیری

بهینه‌سازی کوئری‌های SQL برای عملکرد سریع‌تر یک گام مهم در اطمینان از اجرای کارآمد برنامه‌های پایگاه داده است. از طریق این مقاله، می‌توانیم به نکات زیر برسیم:

- ایندکس‌گذاری مؤثرترین تکنیک برای افزایش عملکرد کوئری‌های SQL است، اما باید ملاحظات بین عملکرد خواندن و نوشتن را در نظر گرفت و تصمیم‌گیری کرد که کدام ستون‌ها باید ایندکس شوند و کدام نوع ایندکس‌ها باید استفاده شوند.(ایندکس ها مثل چاقو دو لبه هستند اگر اشتباه استفاده شوند میتوانند موجب سربار شوند اعمال کردن آنها به درستی نیاز به کمی تخصص دارد )
- بهینه‌سازی کوئری‌های SQL یک فرآیند پیوسته است و نیاز به مانیتورینگ و تنظیمات منظم برای اطمینان از بهبود مداوم عملکرد دارد.
- باید استفاده از عملیات هزینه‌بر مانند JOIN، GROUP BY، IN و زیرکوئری‌ها را به حداقل رساند تا عملکرد بهبود یابد.
- کوئری‌ها را بر روی مجموعه‌های داده واقعی آزمایش کنید تا اطمینان حاصل شود که بهینه‌سازی‌ها تأثیر مطلوبی دارند.

منبع

#SQL
@Code_Crafters

تاکتیک طراحی

تا کنون در خصوص چه چیزی و چرایی صحبت کردیم، ازین ببعد میخواهیم راجب چگونگی صحبت کنیم

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

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

اسکریپت تراکنش:

منطق تجاری را با رویه هایی سازماندهی می کند، که در آن هر رویه یک درخواست واحد از ارائه را مدیریت می کند

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

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

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

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

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

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

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

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

#DDD
#domain_driven_design

@code_crafters

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


رکورد فعال(active record):
یک شی که یک ردیف را در جدول یا نمای پایگاه داده می پیچد، دسترسی به پایگاه داده را کپسوله می کند و منطق دامنه را روی آن داده اضافه می کند, شبیه الگوی اسکریپت تراکنشی حالت‌های مختلفی رو پشتیبانی میکند، جاییکه منطق تجاری ساده است، با این حال منطق تجاری ممکن است بر روی ساختار داده گسترده تری مانند درختان کار کند

پیاده سازی:
در نتیجه، این الگو از اشیاء اختصاصی، معروف به رکوردهای فعال، برای نمایش ساختارهای داده پیچیده استفاده می کند. جدا از ساختار داده، این اشیاء همچنین روش‌های دسترسی به داده‌ها را برای ایجاد عملیات CRUD پیاده‌سازی می‌کنند. در نتیجه، اشیاء رکورد فعال به یک (ORM) یا برخی چارچوب های دسترسی به داده، دیگر جفت می شوند. نام الگو از این واقعیت گرفته شده است که هر ساختار داده "فعال" است. یعنی منطق دسترسی به داده ها را پیاده سازی می کند. مانند الگوی قبلی، منطق تجاری سیستم در یک اسکریپت تراکنش سازماندهی شده است. تفاوت بین این دو الگو این است که در این مورد، به جای دسترسی مستقیم به پایگاه داده، اسکریپت تراکنش اشیاء رکورد فعال را دستکاری می کند. وقتی کامل شد، عملیات باید به عنوان یک تراکنش اتمی یا کامل شود یا شکست بخورد

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

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

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


عملگرا باشید:
اگرچه داده های کسب و کار مهم هستند و کدی که ما طراحی و ایجاد می کنیم باید از یکپارچگی آن محافظت کند، مواردی وجود دارد که در آنها رویکرد عملی مطلوب تر است.
بخصوص در سطوح بالای مقیاس، مواردی وجود دارد که تضمین‌های سازگاری داده‌ها را می‌توان تسهیل کرد. بررسی کنید که آیا خراب کردن وضعیت یک رکورد از 1 میلیون واقعاً یک عامل نمایشی برای تجارت است و آیا می تواند بر عملکرد و سودآوری کسب و کار تأثیر منفی بگذارد. برای مثال، فرض کنید شما در حال ساختن سیستمی هستید که روزانه میلیاردها رویداد را از دستگاه‌های IoT دریافت می‌کند. آیا اگر 0.001٪ از رویدادها تکراری یا گم شوند، مشکل بزرگی است؟
همه چیز به حوزه کاری که در آن کار می کنید بستگی دارد. فقط مطمئن شوید که ریسک ها و پیامدهای تجاری را ارزیابی کرده اید

#DDD
#domain_driven_design

@code_crafters