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

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

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

پیش بینی های همزمان:
پیش بینی های همزمان تغییرات را در داده های OLTP از طریق مدل اشتراک تکمیلی واکشی می کنند:

• موتور طرح ریزی پایگاه داده OLTP را برای سوابق اضافه یا به روز شده پس از آخرین نقطه بازرسی پردازش شده جستجو می کند.

• موتور پروژکتور از داده های به روز شده برای بازسازی/به روز رسانی مدل های خوانده شده سیستم استفاده می کند.

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

این فرآیند در شکل 8-13 و به صورت نمودار توالی در شکل 8-14 تصویر دوم در کامنت‌ها نشان داده شده است

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

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

#DDD
#domain_driven_design

@code_crafters

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

علاوه بر این، CQRS به طور طبیعی خود را به مدل های دامنه منبع رویداد (وام/قرض) می دهد. مدل منبع رویداد امکان پرس‌وجو از رکوردها را بر اساس وضعیت‌های تجمیع‌ها غیرممکن می‌کند، اما CQRS این کار را با نمایش وضعیت‌ها در پایگاه‌های داده قابل پرسش امکان‌پذیر می‌کند.

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

#DDD
#domain_driven_design

@code_crafters

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

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

منطق ترجمه مدل میتواند بدون حالت یا با حالت باشد ترجمه بدون حالت مانند OHS/ACL صادر می‌شود، در حالیکه ترجمه حالت دار شامل نطق ترجمه پیچیده تری است که به پایگاه داده نیاز دارد

ترجمه مدل بدون حالت(بی تابعیت):
بافت محدودی که ترجمه را در اختیار دارد (OHS برای بالادست، ACL برای پایین‌دست) الگوی طراحی پراکسی را برای مداخله درخواست‌های ورودی و خروجی و ترسیم مدل منبع به مدل هدف بافت محدود پیاده‌سازی می‌کند
(request --> proxy --> target)
پیاده سازی پروکسی به این بستگی دارد که آیا بافت‌های محدود به صورت همزمان یا ناهمزمان با هم ارتباط برقرار می کنند

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

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

#DDD
#domain_driven_design

@code_crafters

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

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

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

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

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

• هم وضعیت کل به روز شده و هم رویدادهای دامنه جدید در یک تراکنش اتمی انجام می شوند.

• یک رله پیام واکشی رویدادهای دامنه جدید از پایگاه داده.

• رله رویدادهای دامنه را در گذرگاه پیام منتشر می کند.

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

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

#DDD
#domain_driven_design

@code_crafters

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

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

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

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

#DDD
#domain_driven_design

@code_crafters

موقعیت اخذ جاب آفر انگلیس

موقعیتهای شغلی:
مدیر فنی
هوش مصنوعی و یادگیری ماشین
دیتا ساینس
مدیر پروژه
دواپس
امنیت
فول استک
اندروید یا ios
و ui ux

یسری توضیحات بدم
۱-ابتدا یه محاسبه فنی از طرف شرکت ما (راهبران رایان فناکو) جهت تایید توانایی تخصصی خواهید شد
۲-آیلتس با نمره حداقل ۵
۳-صد و ده هزار پوند (این پول به حساب خودتون داخل صرافی بلوکه میشه و بعد از استقرار در شرکت و بستن قرارداد با شرکت ثالث پول به حساب شرکت ثالث انتقال میسه)
۴-حقوق دریافتی ماهیانه ۳۸۰۰ پوند و قرارداد اولیه دو ساله است
۵-اخذ اقامت همراه خوانواده یا پارتنر

جهت اطلاعات بیشتر پیام بدید
@behzad_azadi



@code_crafters

طراحی اکتشافی (heuristic)

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

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

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

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

 اکتشافی مفید و آشکار بسیاری برای تعیین مرزهای یک سرویس وجود دارد

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

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

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


#DDD
#domain_driven_design


@code_crafters

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

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

• آیا منطق تجاری ساب دامنه پیچیده است؟  اگر چنین است، یک مدل دامنه پیاده سازی کنید.
 در غیر این صورت...

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

• یک اسکریپت تراکنش را پیاده سازی کنید.

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

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

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

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

• مدل دامنه به معماری پورت ها و آداپتورها نیاز دارد. در غیر این صورت، معماری لایه‌ای باعث می‌شود که تجمیع‌ها و ارزش‌گذاری اشیاء از ماندگاری نادیده گرفته شوند

• الگوی رکورد فعال به بهترین وجه با یک معماری لایه ای همراه با لایه کاربردی (سرویس) اضافی همراه است. این برای منطق کنترل رکوردهای فعال است

• الگوی اسکریپت تراکنش را می توان با معماری لایه ای حداقلی که تنها از سه لایه تشکیل شده است، پیاده سازی کرد.

تنها استثناء اکتشافی قبلی، الگوی CQRS است. CQRS می تواند نه تنها برای مدل دامنه منبع رویداد، بلکه برای هر الگوی دیگری مفید باشد، اگر زیر دامنه نیاز به نمایش داده های خود در چندین مدل پایدار داشته باشد. تصویر دوم در کامنت یک درخت تصمیم برای انتخاب یک الگوی معماری بر اساس این اکتشافات را نشان می دهد.

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

#DDD
#domain_driven_design

@code_crafters

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

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

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

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

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


#DDD
#domain_driven_design

@code_crafters

widenex.com

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

تو قسمت gpts.widenex.com هم براتون افزونه‌هایی گذاشته که با کلیک روی هر بخش از اون مثلا (python) یک فیلتر روی chat gpt شما اعمال میکنه و تمام سوالات شما از بستر این فیلتر مربوط به پایتون عبور میکنه (تو اکثر موارد براتون افزونه داره) تستش کنید بشکل عجیبی انگار chat gpt رادیکالتر و بشدت باهوشتر میشه


#free

@code_crafters

در طی چند روز گذشته بابت استخدامی حدود ۱۴۰ رزومه رو بررسی کردم و برام جالب بود که تمامی رزومه‌ها ایرادات خاصی داشتن از متن و قالب بندی و محتوی و ...

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

این قالب پایه رو درآوردم که مناسب رزومه‌های بین‌المللی هم هستش

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


#free #resumeh

@code_crafters

بعد جا گذاری متن در قالب پیش فرض بالا با استفاده از وبسایت زیر

resumeworded

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

چندتا مورد بهتون بگم:
ایمیل شما باید مختص نام شما و شامل اعداد نشده (حتی شده ته فامیلیتون حرف اخر رو دوبار تکرار کنید ولی عدد داخلش نزارید)

از قالب پیش فرض بالا فراتر نرید

اگه گواهینامه و مدرک معتبر دارید اضافه کنید

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

ساختار متنیتون درست و بدون غلط املایی باشه (از gpt کمک بگیرید دوستان حتی اگر هم شد ببرید تا ترجمه کنن براتون)

رنگهای عجیب و غریب نزارید (رزومه شما تابلو فرش نیست)

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

(همین قالب با ساختار متن درست، رزومه خودم رو ساختم و با استانداردهای بین المللی 85 از 100 گرفت )


@code_crafters

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

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

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

• نحوه طراحی مرزهای زمینه های محدود

• نحوه هماهنگ سازی یکپارچگی بین زمینه ها

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

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

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

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

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

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

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

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

در تصویر اول در کامنت‌ها تغییرات در زیر دامنه ها رو میتونید ببینید


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

#DDD
#domain_driven_design

@code_crafters

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

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

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

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

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

#DDD
#domain_driven_design

@code_crafters

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

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

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

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

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

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

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

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

#DDD
#domain_driven_design

@code_crafters

بعنوان یک مهندس نرم افزار استخدام میشید؟؟؟

از سری روزمرگی‌های سازمانی مهندس نرم افزار توقع شرکت‌ از شما جهت برآورد کردن نیازهاشون هست ما به شما میگیم مهندس نرم افزار یعنی در چند وجه از شما انتظار میرود (رویکردی فنی - دیدگاه مهندسی - پشتوانه علمی) ترکیب این سه تجسم درستی از مهندس نرم افزار ارائه میدهد

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

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


در نهایت با تابلوی همگانی دوست باشید و بهره ببرید ازش تاثیر شگفتی داره در رفتار کارمندان و مدیران شرکت


#daily

@code_crafters

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

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

روند استخدامی در شرکت‌های مطرح چجوریه؟؟

۱ـ بخش فنی اعلام به نیاز نیرو با تخصص‌های مدنظر خود میکنه

۲ـ فراخوان استخدامی در کانال‌ها و رسانه‌ها پخش میشه

۳- از بین رزومه‌های ارسالی، بخش فنی مشخص میکنه چه کسانی صلاحیت رو دارن

۴ـ رزومه‌ها به واحد منابع انسانی ارسال میشه و منابع انسانی در طی تماس با افراد دعوت به مصاحبه رو انجام میده، فرد ابتدا باید چند تست سیستمی که در خصوص سنجش هوش و شخصیت شناسی هست رو انجام بده و این اولین دانه تکانی توسط منابع انسانی است و در مرحله بعد افرادی که سلامت هوشی و شخصیتی دارن دعوت به مصاحبه hr خواهند شد

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


آزمونهای هوش شامل:

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

آزمونها بصورت سیستمی و حداکثر تایم ان دو ساعت است (برخی شرکت‌ها ممکن است آزمون بیشتر یا کمتر داشته باشند)

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

تفکیک این دو‌ دسته سوال از هم امکان پذیر نیست براتون

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

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


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

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


#free

@code_craftets

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

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

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

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

زیردامنه ها

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

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

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

#DDD
#domain_driven_design

@code_crafters

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

مصالح (تجمیع):
اصل راهنمای زیر برای طراحی مرزهای مصالح:

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

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

#DDD
#domain_driven_design

@code_crafters

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

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

با سرچ‌ کردن تو گوگل میشه پیدا کرد این موارد رو

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

https://quickref.me/


#free

@code_craftets