تاکتیک طراحی

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

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

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

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

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

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

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

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

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

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

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

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

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

#DDD
#domain_driven_design

@code_crafters

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


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

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

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

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

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


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

#DDD
#domain_driven_design

@code_crafters