https://virgool.io/feed/@msadeqshajari C#/.NET Developer fa 2026-04-15 09:06:41 https://files.virgool.io/upload/users/255301/avatar/Nim6ze.jpg?height=120&width=120 https://virgool.io/@msadeqshajari https://virgool.io/software-development/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-domain-driven-design-%D8%B7%D9%88%D9%81%D8%A7%D9%86-%D8%B1%D9%88%DB%8C%D8%AF%D8%A7%D8%AF-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-kjvkyyigxg0w در فصول گذشته، آموختیم که شناخت و درک مساله واقعی تا چه میزان با اهمیت است. همچنین در مفهوم Ubiquitous Language عمیق شدیم و شرح دادیم که فقط یک لغتنامه از اصطلاحات نیست، بلکه رفتار سیستم است که در قالب کلمات شرح داده شده اند.اما واضح نشد که چگونه شروع کنیم تا دانش موجود در دامنه را قطعه بندی کنیم و چگونه ارتباطات خود را با متخصصین دامنه تشدید کنیم تا فضای مساله را بهتر درک نموده و دید بهتری نسبت چیزی که می خواهیم بسازیم بدست آوریم.اغلب دیده می شود که توسعه دهندگان، دامین را به عنوان مجموعه ای از نیازمندی ها می شناسند. ما قبلا در مورد این موضوع بحث کردیم و دیدیم که این وابستگی به نیازمندی ها معایب خود را دارند. بنابراین، ما باید زبان خود را با صحبت مستقیم با متخصصین دامین بهبود بخشیم و جلساتی را با آنها سازماندهی کنیم. برخی از افراد به این جلسات آمده و برای 2 الی 3 ساعت باهم صحبت می کنند. درباره بسیاری از مسائل بحث خواهد شد و بینش های فراوانی به شما افزوده می شود، اما خروجی حداقلی از هر نوع از مدل سازی بدست می آید. در این مرحله حتما می توانید نمودار های UML طراحی کنید، اما چگونه شخصی که در آن کسب و کار است، متوجه این نمودار شود؟ همچنین شروع به یادداشت نکات برای آموختن آنچه نیاز دارید می کنید. اما از آنجا که مفاهیم ضمنی و مبهم زیادی وجود دارد که پایه های سیستم آینده شما را تشکیل می دهند، باعث می شود درک آن بسیار سخت باشد.چندین مشکل اساسی وجود دارد که نیاز به رفع آنها داریم:شفافیت در طول صحبت ها. وقتی افراد زیادی در مورد یک موضوع واحد به شکل های مختلف صحبت می کنند، فرضیات را بوجود می آورند.داشتن یک زبان مدلسازی شده که افراد آن را درک کنند. نمودار های UML در اینجا جزو گزینه ها محسوب نمی شود چرا که باکس ها و فلش هایی که در آن استفاده می شود، نماد حقیقت نیستند. پس افراد شروع به سردرگمی کرده و به صرف زمان برای شفاف سازی معانی چیزها می پردازند.افراد زیادی را به طور همزمان درگیر کنید. در جلسات سنتی، فقط یک نفر می تواند پیام را بدرستی منتقل کند، در حالیکه بقیه افراد باید فقط ساکت بوده و گوش دهند. به محض اینکه افراد زیادی همزمان شروع به صحبت کنند، دیگر مکالمه مفیدی شکل نمی گیرد. با فرض افرادی با علایق و زمینه های مختلف که در جلسه حاضر هستند، پس از مدتی ممکن است علاقه شان را از دست داده و خسته شوند.یافتن راهی برای ارائه اصطلاحات، رفتارها، فرایندهای مدل و تصمیمات، و نه ویژگی ها و دیتاها.در سال 2003، آلبرتو برندولینی، روشی را ابداع کرد و آن را طوفان رخداد (Event Storming) نامید. روشی که تلاش دارد مشکلاتی که در بالا مطرح شد را برطرف کند. ما در این فصل در مورد این روش خواهیم آموخت.مدلسازی زبانایده اصلی پشت طوفان رویداد این است که یک نماد مدل سازی ساده ارائه می دهد که به منظور مصور سازی رفتار سیستم به گونه ای که همه متوجه آن شوند، استفاده می شود. این رویکرد، شفافیت ایجاد می کند، تعامل را افزایش می دهد و افرادی را درگیر می کند که به هر دلیلی در مورد مشارکت در جلسه مدل سازی یا نوشتن چیزی روی وایت برد، مضطرب بوده اند.با در نظر گرفتن رفتار، بعنوان جنبه اصلی دانش دامین، تمامی تمارین طوفان رویداد در مورد این است که متوجه شویم آن کسب و کار چگونه کار می کند. بطور کلی، می توانیم این طور فرض کنیم که هر سیستم در هر لحظه از زمان، در یک حالت خاص یافت می شود. این حالت خاص می تواند با تعاملاتی که بازیگران آن سیستم دارند، تغییر یابد. عملیاتی که این بازیگران انجام می دهند، مسبب تغییر وضعیت سیستم شده، بنابراین می توانیم ببینیم که اتفاقی رخ داده و اکنون باید با این وضعیت جدید سروکار داشته باشیم.بیایید نگاهی به یک مثال ساده از کسی که قبض اش را توسط اینترنت بانک پرداخت می کند، کنیم:سلسله رخدادها برای فرایند پرداخت (ساده شده)همانطور که می بینید، از نگاه شخصی که پرداخت می کند، مبلغ پولی که در حسابش داشت، کاهش پیدا می کند، پرداخت با موفقیت انجام می گردد و قبض پرداخت شده محسوب شده و می توان آن را دور انداخت! از نگاه دریافت کننده، قبض زمانی پرداخت شده محسوب می شود که پول را دریافت کنند و بتوانند این پرداخت را با یک قبض باز (پرداخت نشده) توسط شناسه قبض مطابقت دهند.هر عملی توسط بازیگران این سیستم، باعث برخی تغییر حالات می شوند. سفارش پرداخت ایجاد شده و ثبت شد. مبلغ قبض از حساب پرداخت کننده کسر شد. این مبلغ به حساب دریافت کننده افزوده شد. قبض "پرداخت شده" علامت گذاری شد. تمامی این عملیات، حقیقت های واقعی زندگی هستند و تا زمانی که ماشین زمان نداشته باشیم، نمی توانیم آنها را بازگردانیم. اگر دریافت کننده تشخیص دهد که قبض قبلا پرداخت شده بوده است، آن ها نمی توانند چیزی را بازگردانند. آنها مجبور به بازگشت پول در یک رخداد پرداخت جدید هستند.این حقایق بعنوان رخداد های دامین شناخته می شوند. این ها مفاهیم اولیه اما در عین حال مهمی هستند که طوفان رویداد با آنها سر و کار دارد. به همین دلیل هست که این اسم برای آن انتخاب شده است. ایده رخدادهای دامین برای هیچ کس غریبه نیست. حقایق واقعی زندگی چیزهایی هستند که مردم می توانند به راحتی آن را درک کنند. آن ها چیزی هستند که اتفاق می افتد، نه چیزی که برخی می خواهند آن را انجام دهند. نه یک ویژگی و نه ظاهر یک دکمه در سایت. هر رخداد دامین نشان دهنده یک حقیقت است. یک تغییر در سیستمی که می خواهیم آن را مدل سازی کنیم.بنابراین، اولین بخش از مدلسازی زبان ما ایجاد مفهوم رخدادهای دامین است. هر مفهومی در طوفان رویداد، توسط یک برچسب با رنگی مشخص نشان داده می شود. رنگ در اینجا ضروری است. چرا که هرچه جلوتر رویم و افکار بیشتری برای مدل سازی بیاوریم، به آن ها نیاز داریم تا ایده های یکسان در طول مدل را به منظور رفع سردرگمی نمایش دهیم. پیشنهاد اصلی که آلبرتو دارد، استفاده از برچسب های نارنجی برای نمایش رخداد های دامین است. ساده ترین حالت ممکن از مدل می تواند چیزی شبیه به این باشد:از نقطه کوچکی شروع کرده و از آنجا ادامه دهیدتصویر بالا نمایانگر دو رخداد دامنه است که به ترتیب رخ می دهند. اول، یک مشتری توسط کارت اعتباری خود پرداخت را انجام می دهد، سپس سفارش تایید می شود. می توانیم تشخیص دهیم که این مربوط به یک دامین ایکامرس است. هیچ چیز عجیب و خاصی در مورد متونی که در برچسب استفاده می شود وجود ندارد، بجز یک قاعده بسیار مهم. رخداد ها باید فاعل و فعل داشته باشند. فعل باید در آخرین عبارت به کار رود که نشان دهنده این است که چیزی رخ داده است.اگر به مثال پرداخت قبض برگردیم، می توانیم تلاش کنیم تا رخدادهایی که آنجا رخ می دهد را بیابیم:رخدادها در یک تایم لاین قرار گرفته اندچندین نکته در تصویر بالا وجود دارد که احتمالا به سرعت متوجه آنها شدید. اولین نکته این است که رخدادهای دامین، یک تایم لاین را دنبال می کنند. این کار تقریبا منطقی است، چرا که رخدادها بیانگر تغییرات بعدی در سیستم هستند، لذا در یک ترتیب مشخصی اتفاق می افتند. بعنوان مثال، پرداخت قبل از ثبت شدن نمی تواند تایید شود. برخی از موارد ممکن است به صورت موازی اتفاق بیفتد، مانند بدهکار و بستانکار کردن حساب های پرداخت کننده و دریافت کننده به صورت همزمان، به محض تأیید دستور پرداخت، که ممکن است به این معنی باشد که بانک اطمینان دارد که پرداخت کننده دارای وجوه کافی برای تکمیل پرداخت است.نکته دوم این است که ما فقط یک سیستم در اینجا نداریم. در واقع ما کل فرایند را مدلسازی کرده ایم. اما حداقل سه بخش وجود دارند که به وضوح می توانیم آنها را تشخیص دهیم. اینترنت بانک کاربر که سفارشات پرداخت را ایجاد و ثبت می کند. واحد پشتیبانی بانک که تراکنش را تکمیل می کند. و سیستم مطابقت پرداخت به قبض برای دریافت کننده که حتی ممکن است بصورت دستی انجام شود.تصویر سازی (Visualization)همانطور که در بخش قبل دیده شد، مدل ساده ای که طراحی کردیم، ارزش های فراوانی برای افراد درگیر در ورکشاپ رونمایی کرد. نه تنها تلاش کردیم آنچه در طول پرداخت یک قبض بوجود می آید را شناسایی کنیم، بلکه کل جریان را در یک تایم لاین ترسیم کردیم و قادر شدیم بخش هایی از فرایند را که در هر سیستم فیزیکی رخ می دهد را به خوبی شناسایی کنیم.تصویرسازی یکی از قوی ترین جنبه های تکنیک های مدل سازی است. طوفان رویداد نیز از این رویه مستثنی نیست. به محض اینکه چیزی را به مدل خود اضافه می کنیم، می توانیم منطق پشت این کار را بیان کنیم، جای اینکه فقط کلمات را هجی کرده و دستانمان را تکان دهیم!زمانی که افراد تصویر کلی از آنچه رخ می دهد را می بینند، ممکن است سوالاتی را که با عبارت چه می شود اگر؟ مطرح می کنند.چه می شود اگر پول کافی در حساب نباشد؟ چه می شود اگر شماره رفرنس قبض صحیح نباشد؟ چه می شود اگر حساب دریافت کننده صحیح نباشد؟ چه می شود اگر ...؟ اینجاست که مشخص می شود مدل ساده ما در انتها به این سادگی باقی نخواهد ماند. عبارت دسترسی اکتشافی را به یاد آورید، آیا آنچه می بینید، تمام چیزی است که وجود دارد؟ ما از درک اولیه خود بعنوان پایه ای برای نگاهی ساده به دنیا استفاده می کنیم. همه چی آنطور که باید، عمل می کند. هیچ استثنایی وجود ندارد، مردم برای اشتباه کردن برنامه ریزی نمی کنند. اما دنیا کمی پیچیده تر از این است. موارد پیش بینی نشده نسبت به جریان منطقی رخداد ها بیش از آن چیزی است که ما به آن فکر کرده باشیم. تمامی این موارد پیش بینی نشده و استثنائات زمانی که چیزها مصور می شوند، بیشتر نمایان می شوند و چون چراغی در تاریکی می مانند.یک مساله ای اینجا پیش می آید، که می تواند برای کسانی که بهترین تلاششان را برای ساخت یک مدل رخداد انجام می دهند زیان آور باشد. تصور کنید چنین ورکشاپی در یک اتاق جلسه برگزار می شود. معمولا افراد بین یک میز نشسته و صحبت می کنند. همانطور که قبلا گفتیم، این روشی نیست که طوفان رویداد از آن استفاده می کند. ما از افراد انتظار داریم که در اتاق حرکت داشته باشند و فعالانه در بحث مشارکت کنند. این مشارکت ممکن است به صورت همزمان در نقاط مختلفی از اتاق رخ دهد. پس ما نیاز به فضای بیشتری داریم. اما این همه فضایی نیست که به آن نیاز داریم. داشتن نگاه درست به مدل فرایندی ساده گذشته. اگر چه توافق داریم که مدل ما فقط مسیر شادی (happy path) را در نظر گرفته و استثنائات (edge cases and exceptions) را نادیده گرفته، اما می دانیم که دنیای واقعی این گونه برخورد نمی کند. نمودار ساده ما هم اکنون نیز فضای افقی ای را گرفته است. حالا فرض کنید سناریوهای دنیای واقعی اینگونه مدل سازی شوند. در واقع یک وایت برد 2 3 متری برای شما نمی تواند به درستی خدمات دهی کند!تصور کنید مدل شما چیزی شبیه به این است:برای یک سیستم منطقی پیچیده، شما به فضای بزرگتری نیاز داریدقسمت هایلایت شده عکس، وایت برد شماست. اما مدل شما در آن جا نمی شود. همانطور که آلبرتو گفته است، مشکل من بزرگ تر است!چه زمانی رخ می دهد وقتی که فضای کافی روی تخته وجود نداشته باشد؟ افراد بعنوان یک منبع ترسناک به فضای باقیمانده نگاه می کنند. این فضا گرانبها شده و افراد شروع به ذخیره فضا می کنند. برخی رخداد ها تبدیل به بی اهمیت می شوند پس داخل وایت برد وارد نمی شوند. برخی رخداد ها ثانویه محسوب شده و ارزش نگاه کردن ندارند. در نهایت، مدل سازی ما قربانی حفظ کمی فضا در وایت برد می شود!این اتفاق، اتفاقی طبیعی است و مغز ما اینگونه کار می کند. اگر برخی محدودیت ها را ببینیم، مهم نیست نتیجه کارمان چقدر بد و نامطلوب شود، ما فعالیت هایمان را بر اساس فضای فیزیکی که داریم محدود می کنیم. اگر یک فضای محدود برای مدلسازی دارید، انتظار دریافت یک مدل محدود و ناقص را داشته باشید. پس، نسبت به این موضوع آگاه باشید و فضایی برای مدل سازی ایجاد کنید که برای همه مشارکت کنندگان جلسه طوفان رویداد کافی باشد.پایان بخش اول صادق شجری صادق شجری Mon, 29 Jul 2024 10:43:43 +0330 https://virgool.io/software-development/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-domain-driven-design-%D8%B2%D8%A8%D8%A7%D9%86-%D9%88-%D8%B2%D9%85%DB%8C%D9%86%D9%87-ufdyxcdo434v در آغاز این فصل، اشاره ای به تفاوت های زبانشناسی در یک زبان کردیم. ما از زبان انگلیسی که در امریکا و انگلیس استفاده می شد مثال زدیم که جملات مشترک ممکن است معانی مختلفی در این دو کشور داشته باشند. مثال های فراوانی از این دست وجود دارد. همین اتفاق در زبان گروههای حرفه ای نیز مشاهده می شود. جایی که افراد اصطلاحات تخصصی را توسعه می دهند. مثال هایی از این موارد هم اشاره کردیم.این مثال ها، اهمیت تعریف دقیق معانی کلمات را مشخص می کنند. اجتناب از سردرگمی در واقع یکی از اهداف شناسایی زبان مشترک و فراگیر (Ubiquitous Language) است.فهم این نکته اهمیت زیادی دارد که زبان مشترک و فراگیر تنها داخل زمینه (context) خودش اعتبار دارد. یک زمینه متفاوت با زبان متفاوتی تعریف می شود. یک اشتباه رایج در درک زبان مشترک و فراگیر وجود دارد که عبارت مشترک و فراگیر اشاره به یک زبان واحد برای کل کسب و کار، سازمان یا دامین دارد. در حالی که اینطور نیست. مشترک و فراگیر بودن آن، افقی نیست. بلکه عمودی است. هر زمینه ممکن است زبان خاص به خود را داشته باشد،در عین حال این امکان وجود دارد تمامی لایه ها در این زمینه؛ یک زبان مشترک و فراگیر واحد را به اشتراک گذارند.بیایید نگاهی به یک مثال کلاسیک از عبارت محصول (product) در زمینه های متفاوت از دامین خرید و فروش بیاندازیم:محصول، در زمینه های مختلفاگر چه ما در یک دامین مشترک هستیم، اما واژه Product معانی و مفاهیم مختلفی در هر یک از زمینه های مشخص شده دارد: فروش (Sales): برای فروشندگان، محصول به معنی قیمت فروش و حتی حاشیه سود است. جایی که شرکت از آنجا پول بدست می آورد و سایر خصوصیات محصول اهمیتی ندارد.خرید (Purchasing): اگر یک محصول را خریداری کرده باشیم به نیت فروش مجدد آن، ما بیشتر از همه به قیمت خرید علاقمند هستیم. اینکه چقدر از یک کالای در انبار تامین کننده موجود است؟ و اینکه آن کالاها در چه فاصله زمانی بعد از سفارش به ما خواهند رسید؟فهرست موجودی (Inventory): ما بیشتر از همه علاقمند به دانستن تعداد هر چیزی در انبارمان هستیم. اگر موجودی کالایی کمتر از حد انتظار باشد، می توان تاریخ تخمینی برای سفارش و دریافت مجدد کالا را در این زمینه (context) در نظر گرفت. در اینجا ما احتمالا برخی خصوصیات داخلی محصول مانند شماره انبار آن محصول را نیز تعریف می کنیم.انبار (Warehouse): نیاز به مدیریت فضایی دارد که برای نگهداری محصولات مورد نیاز است. پس افرادی که در این زمینه حظور دارند، نیاز دارند تا زمان رسیدن کالاهای جدید به انبار را بدانند. و اینکه چگونه باید آنها را دسته بندی کنند. و در کجا هر محصول را ذخیره سازی کنند.همانطور که می بینید، اگر چه ما یک اصطلاح رایج مانند محصول را داریم، اما دپارتمان های مختلف از یک دامین مشترک یا سازمان نیز خصیصه های مشترک بسیار کمی از مفهوم آن در بخش های خودشان دارند و هر زمانی که در هر بخش به معنی و مفهوم آن عمیق می شویم، مشاهده می شود که ویژگی های خاص به آن بخش به آن کلمه اعتبار و مفهوم متفاوت می دهد.مثال بالا نشاندهنده این است که حتی در یک دامین خاص، زمینه های مختلفی می تواند وجود داشته باشد که زبان در آنجا تغییر نموده و برخی اوقات این تغییرات بسیار فاحش هستند. اما چه اتفاقی رخ می دهد اگر ما از یک معنی در تمام زمینه ها استفاده کنیم؟ این کار باعث می شود که مسائل، کمتر صریح باشند. درجات ابهام با هر زمینه جدید، افزایش می یابد و باعث می شود در تفکیک و شناسایی آنها در زمینه های مختلف به مشکل بر بخوریم. اینها باعث ایجاد یک مدل غیرشفاف می شوند و در نتیجه مسبب کد مبهم می شود. جائیکه نیاز پیدا می کنیم مشخص کنیم که منظور ما از آن کلمه در آن زمینه، دقیقا چیست؟ مخلوط کردن زمینه های مختلف در یک محیط کاری نیز شما را به سمت چیزی به نام تغییر زمینه (context switching) هدایت می کند. جرالد وینبرگ در کتاب خود اینطور تخمین می زند که بالا رفتن تعداد پروژه هایی که یک فرد روی آن کار می کند، باعث افت شدید بهره وری آن شخص بدلیل همین تغییر زمینه می شود.کاهش بهره وری بدلیل تغییر زمینه هاافزودن یک پروژه به پروژه های کنونی به معنی کاهش 20 درصدی بهره وری شما می باشد. اگر تعداد زمینه های مختلف شما به 5 برسد، مقدار زمانی که مفید روی کارها می گذارید، به شدت کاهش می یابد. زمان زیادی از شما صرف این مساله می شود که متوجه شوید کدام زمینه متعلق به پروژه یا تسک جاری شماست.این قاعده فقط برای پروژه ها معتبر نیست. ممکن است زمانیکه تعمیم (generalization)، بر دقت و عدم ابهام غالب شود، پدیده تغییر زمینه بوجود آمده و به همان اندازه که گفته شد، بر روی عملکرد شما تاثیر گذار باشد. در مثالی که در مورد Product بیان شد، اگر ما تمام خصوصیات Product که از هر زاویه دیدی وجود دارد را در یک کلاس تعریف کنیم، کار با چنین آبجکتی مستلزم تلاش بیشتر و همچنین تلاش برای درک آن بخش از Product با توجه به زمینه ای که در حال کار با آن هستیم، دارد. بنابراین، با اینکه داریم بر روی یک چیز کار می کنیم، دچار تغییر زمینه مخفی شده ایم و به مضرات آن دچار خواهیم شد.فرض کنید که تمرکزگرایی و تعمیم پذیری، چیزهای خوبی بودند و بسیاری از شرکت ها، کلاس هایی (God classes) مانند Customer یا Product ایجاد می کردند که شامل تمام خصوصیات ممکن از همه زوایای مختلف بود. علاوه بر تغییر زمینه ای که رخ می داد، معایب دیگری نیز بوجود می آمد.یکی از معایب واضح، این است که در طول یک چرخه عمر مشخص از چنین آبجکتی در سیستم، همه خصوصیات مورد نیاز ما نیستند. برای مثال، محصول از رده خارج شده، هیچ ویژگی ای ندارد که مرتبط با بخش فروش باشد. اما چون ما یک کلاس برای همه خصوصیات داریم، مجبور هستیم مقادیر خالی را برای تمامی محصولات ایجاد کنیم. چنین رویکردی ما را به سطح بالایی از سردرگمی می رساند چرا که ما به سختی متوجه این خواهیم شد که چرا این خصوصیات، بی استفاده هستند. اشتباهی در سیستم هستند و یا یک وضعیت معمولی با توجه به وضعیت آبجکت هستند؟مساله دیگر این است که ناچارا این کلاس ها دارای وابستگی های زیادی می شوند. احتمالا دیتامدل هایی را دیده اید که سیستم با تمام پیچیدگی هایش، فقط یک دیتابیس SQL بزرگ دارد که جداول آن رفرنس های زیادی به یکدیگر دارند. می توانیم اینطور فرض کنیم که جدولی مانند Product با جداولی چون Order,ShoppingCart, Catalogue,Invoice,PurchaseInvoice, Return, CreditNote و ... رفرنس دارد. این مدل به سرعت درهم می شود و نگهداری آن بسیار دشوار می شود. برخی اوقات، اوضاع از این هم خراب تر می شود. مثلا فرض کنید مشخصات یک محصول تغییر می کند. اما نباید مشخصات محصول برای خرید های قبلی که از آن انجام شده دچار تغییر شود. هر سفارش باید کپی خودش از محصول خریداری شده را در لحظه خرید، ضبط کند.به اندازه کافی علت اینکه باید مراقب فراموش نکردن زمینه ها باشیم را متوجه شدیم. زبان مشترک و فراگیر (Ubiquitous Language)، همیشه باید بدون ابهام، صریح و مختص به زمینه (context) باشد. به محض اینکه حس کردید معانی کلمات شروع به تغییر در بخش های مختلف سیستم کردند، باید هشداری در درون شما را فعال کند که در حال عبور از مرزبندی های آن زمینه هستید.هنگام بحث در مورد کاربران، زمینه مطرح می شود. توسعه دهندگان مایل اند به مردم به عنوان کاربر نگاه کنند. این اصطلاح خیلی مبهم است. تا آنجائیکه تقریبا می توان تضمین داد که زمانی که در مورد کاربران در حال صحبت هستیم، در حال تغییر بین زمینه های مختلف هستیم.به دامین نمونه خودمان بازگردیم. جایی که توسعه دهندگان در حال بحث در مورد چگونگی امتیازدهی کاربران به معاملات خودشان هستند. آنها به این فکر کردند که اگر مردم بتوانند به یکدیگر امتیاز دهند، به آنها در ایجاد اعتماد در جامعه شان در نرم افزار کمک می کند. برخی از آنان متوجه شدند که از کلمات << کاربر، فروشندگان، آنها که می فروشند، آنها که می خرند و خریداران>> دارند به جای هم استفاده می کنند. وقتی که اصطلاح عمومی کاربر استفاده می شد، همیشه نیاز به شفاف سازی داشت: این کاربر چه نقشی در آن لحظه دارد ایفا می کند؟ همزمان، وقتی کاربران را به نام های خریدار یا فروشنده صدا می زدند، ابهامی بوجود نمی آمد و نیاز به شفاف سازی نبود.پس از این، گروه متوجه شد که المنت های جدیدی از Ubiquitous Language را کشف کرده و شروع به استفاده از این اصطلاحات کرد. این کار بینش خوبی به آنها داد که زمانی زیادی از بحث آنها را در مورد مدل ها صرفه جویی نمود و ابهام در کد را نیز از بین برد.همزمان، تفکیک مردم به خریدار یا فروشنده در قسمت اعتبار سنجی (authorization) سیستم منطقی به نظر نمی رسید. آنها فقط کاربر هستند که می توانند به سیستم لاگین کرده و برخی عملیات انجام دهند. مانند بروزرسانی پروفایلشان. بدون توجه به اینکه بین خریدار بودن یا فروشنده بودن آن فرد در سیستم، تمایزی قائل شویم. این خود یک زمینه دیگر است که کلمه user ابهامی ندارد و صریح است.بعدا، مجددا آنها گونه دیگری از کاربران را یافت کردند که نیاز به مدل شدن در سیستم داشت. جائیکه کاربران شروع به گرفتن نقش های مختلف می کردند. و مجددا ابهام بوجود آمد تا آنها شروع کردند به استفاده از اصطلاحاتی چون administrator، support assistant و reviewer. زمینه جدیدی یافت شد و مدل جدید برای آن ایجاد شد که از زمینه های دیگر با توجه به معانی کلمات استفاده شده در آنها تفکیک گشت. صادق شجری صادق شجری Tue, 23 Jul 2024 13:00:54 +0330 https://virgool.io/software-development/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-ddd-%D9%85%D8%AB%D8%A7%D9%84-%D8%B2%D8%A8%D8%A7%D9%86-%D8%AF%D8%A7%D9%85%D9%86%D9%87-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AA%D8%A8%D9%84%DB%8C%D8%BA%D8%A7%D8%AA-%D8%B7%D8%A8%D9%82%D9%87-%D8%A8%D9%86%D8%AF%DB%8C-%D8%B4%D8%AF%D9%87-b7h5yrs9xclw در بخش های قبلی، در مورد پروژه تستی که در طول دوره به تکمیل آن خواهیم پرداخت، صحبت کردیم. اینکه پروژه ای شبیه به پلتفرم دیوار که افراد می توانند ابزار و لوازم اضافه خود را به دیگران که به این لوازم نیاز دارند بفروشند یا اهدا کنند.برنامه نویسان ما در مورد جریان انتشار تبلیغات طبقه بندی شده در حال بحث و گفتگو بودند. آنها از فرایند ایجاد تبلیغات عبور کرده و به نقطه ای رسیدند که کاربر دکمه انتشار را می زند. ما و متخصص دامنه، فهمیدیم که نباید بلافاصله بعد از زدن این دکمه، آن آگهی انتشار پیدا کند، چرا که ممکن است دارای محتوای نامناسب باشد. آنها تصمیم گرفتند که فرایند تاییدی را تعریف کنند که پس از کلیک بر روی انتشار آغاز می گردد و پس از گذراندن این فرایند، تبلیغ در وب سایت به کاربران نمایش داده می شود.توسعه دهندگان به سرعت تصمیم گرفتند یک خصیصه Status به کلاس دامین ClassifiedAd اضافه کنند. نوع این خصیصه Enum است که نشان دهنده وضعیت های مختلف فرایند بازبینی و انتشار تبلیغ است. همچنین این خصیصه بعدا می توان بعنوان وضعیت هایی که هنوز برای ما ناشناخته هستند و ممکن است بعدا بوجود بیایند نیز استفاده شود. از آنجائیکه آنها می خواهند رفتارها را در مدل دامین پیاده سازی کنند، متد UpdateStatus را نیز به کلاس اضافه کردند که شبیه به کد زیر شد: https://gist.github.com/msadeqshajari/7b4e0f3fe66c9b6ab619b3a239062af0 حالا که متد، یک رخداد دامین را نیز منتشر می کند، سایر اجزای سیستم می توانند این رخداد را subscribe کنند و عملیات مقتضی با آن را انجام دهند.ما در ادامه بخش ها در این دوره بیشتر در مورد event ها و command های دامین صحبت می کنیم و توضیح می دهیم. پس بعد از اینکه کاربر بر روی انتشار کلیک کرد، کد زیر اتفاق می افتد:ad.UpdateStatus(ClassifiedAdStatus.Published);و بعد از اینکه بازبینی به اتمام رسید، تبلیغ فعال می شود:ad.UpdateStatus(ClassifiedAdStatus.Activated);به نظر همه چیز قابل قبول است. کلاس ClassifiedAd ما یک state machine است. یعنی جائیکه نمونه هایی از این کلاس در چرخه عمر یک تبلیغ از یک وضعیت به وضعیت دیگر حرکت می کنند. با این وجود، ما هدف را گم کردیم. زبان ما عجیب شد! بجای اینکه بگوئیم ما می خواهیم که تبلیغ را منتشر کنیم، می گوئیم، ما وضعیت تبلیغ را تغییر می دهیم. بجای فعال سازی تبلیغ، مجددا می گوئیم وضعیت تبلیغ را تغییر می دهیم!بعد از چندین تغییر در سیستم، به نظر می رسد که کد درست کار می کند: https://gist.github.com/msadeqshajari/6699a80339497ac8e996e9c086cff269 این قطعه کد، کدی نیست که انتظار داشتیم برای این متد ساده نوشته شده باشد. این متد، وظایف زیادی را متحمل شده است و بلاک های منطقی این کد به سختی با یکدیگر در ارتباط هستند. اما مشکل بزرگتر زمانی پدیدار می شود که می خواهیم رخداد دامین را مدیریت کنیم: https://gist.github.com/msadeqshajari/b9d106b0dac3ea4c8611a68ba32b6719 تعداد عملیات های کنترل جریان کد رشد پیدا می کند و بیشتر رفتار کد اکنون توسط بروزرسانی وضعیت ها هدایت می شود. چیزی که در ابتدا یک عملیات مشخص و کوچک بر روی یک خصیصه از آبجکت دامین به نظر می رسید. هدف ما که بروزرسانی وضعیت بود، منحل شده است و هر قسمت از کد باید به شدت کنترل شود تا اثرات جانبی مخربی نداشته باشد. اکنون ریسک آسیب به رفتارهای کنونی با افزودن کدهای جدید، جدی شده است.صحبت هایی که با متخصص دامنه شده بود نیز معانیشان را از دست دادند. بجای استفاده از عباراتی چون - اگر محتوای مخربی یافت شد، ما تبلیغ را مخفی می کنیم و گروه نظارتی خود را مطلع می کنیم- تبدیل شد به -اگر محتوای مخربی یافت شد، تمام تبلیغات با وضعیت MaliciousContentDetected را درخواست می کنیم و از سرویس نوتیفیکیشن برای رساندن یک پیام به کاربرانی که نقش نظارتی دارند استفاده می کنیم.-معانی موجود در زبان، پشت مفاهیم فنی گم شدند و با عباراتی کلی و عمومی مانند وضعیت و پیام ترکیب شدند.تیم تصمیم گرفت که کد را بازنویسی کرده و از زبان مدل متناسب استفاده کند. خروجی کار آنها این کد بود: https://gist.github.com/msadeqshajari/f0485b7a5e49bae2ea576443f334557c اکنون، همچنین می توانیم کنترلگر رخداد دامین را نیز به شکل زیر بازنویسی کنیم: https://gist.github.com/msadeqshajari/6d336646dbed8aa2396fc2313cea742b سپس برای مدیریت تبلیغاتی که محتوای نامناسب داشتند، می توانیم یک کنترلگر رخداد جدید ایجاد کنیم: https://gist.github.com/msadeqshajari/7d017c66a59a0109780374236a33c9d7 مثال های کوچک ما همچنین نشان می دهد که زبان دامین نمی تواند توسط ایجاد یک لغت نامه با اسامی ساخته شود. یک درک اشتباه درباره جمع آوری اسامی در یک لیست بلند بالا و صدا زدن این لیست بعنوان زبان دامین وجود دارد. این کار، مسیر درستی نیست و معمولا شما را به سمت یک مدل ضعیف (anemic model) هدایت می کند، که بعنوان یک آنتی پترن شناخته می شود. کلاس ها در این مدل، فقط شامل خصوصیات (properties) هستند و این خصوصیات همیشه توسط اسامی نام گذاری می شوند. اما بخش دیگری که اهمیت یکسانی با خصیصه ها دارد، رفتارهای یک مدل دامین هستند. اسامی بیانگر چیزهایی هستند که دامین با آنها اجرا می شود، اما افعال، چگونگی انجام کارها را نشان می دهند. بدون افعال، دامین ما با تغییرات خصیصه ها به سمت انجام عملیات های جادویی پیش می رود، بدون اینکه دلیل مشخصی برای آنها وجود داشته باشد. اما کدهای بالا واضحا بیانگر رفتار دامین توسط تعریف افعال بعنوان بخشی از زبان دامین هستند. این افعال (functions)، دقیق هستند، هدف را نشان می دهند و عملیات را شرح می دهند. در مثال گفته شده، ما نه تنها کد را بهبود بخشیدیم و درک صحیح تری از آنچه کد انجام می دهد و از مفاهیم موجود در آن بدست آوردیم، بلکه برخی اصطلاحات و مفاهیم جدیدی که مدل دامین ما از آن بهره می برد را کشف نمودیم. ما می توانیم از این اصطلاحات جدید در صحبت هایمان با متخصص دامین استفاده کنیم و ببینیم آیا آنها متوجه منظور ما می شوند یا خیر. برخی اوقات، ممکن است نگاهی عجیب به توسعه دهندگان کنند، چرا که در حال درک هیجان خود هستند چون آنها این اصطلاحات جدید رو از قبل می دانستند. زیرا این اصطلاحات مربوط به زبان آنهاست و آنها هیچوقت از این اصطلاحات در مکالمات بین کسب و کار و توسعه دهندگان استفاده نکرده بودند. پس چنین اقداماتی، نه تنها کد های بهتر و نزدیک تر به مدل کسب و کار واقعی را ایجاد کردند، بلکه ارتباطات بین متخصصین دامنه و توسعه دهندگان را نیز بهبود بخشیدند.با تبدیل مفاهیم ضمنی به مفاهیم صریح، نه تنها مفاهیم فراموش شده را در کدهایمان اکتشاف می کنیم، بلکه آن ها را به مدل دامین خودمان نیز می افزائیم. این بخش از کار ضروری است چرا که این زبان در تمام مدل هایی که مربوط به این دامنه هستند، استفاده می شود. هم مدل های کسب و کار و هم مدل های ذهنی، بصری و مفهومی مربوط به دامین در نمودار ها و در کدها. این الگوی استفاده از مفاهیم یکسان، یا به طور کلی، زبان یکسان در مراحل مختلف مدل ها در یک سیستم را زبان مشترک (Ubiquitous Language) می نامند. صادق شجری صادق شجری Sat, 20 Jul 2024 19:58:29 +0330 https://virgool.io/software-development/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-domain-driven-design-%D8%B5%D8%B1%DB%8C%D8%AD-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B3%D8%A7%D8%A6%D9%84-%D8%B0%D9%87%D9%86%DB%8C-edcm2jnejuib زمانی که بر روی یک سیستم جدید شروع به کار می کنیم، نیاز به یاد گرفتن زیادی داریم. همانطور که در فصل قبل گفته شد، تقریبا بالاترین درجه جهالت و به طبع آن، پایین ترین سطح دانایی، زمانی رخ می دهد که تصمیمات فراوانی درباره آینده سیستم میگیریم. ما نه تنها از عدم دانایی در مورد دامین کسب و کار رنج می بریم، بلکه مجبور هستیم در محیطی با سطح بالایی از ابهام کار کنیم. قبل از اینکه در مورد زبان دامنه یاد بگیریم، از درک خودمان از موضوع استفاده می کنیم که غالبا بر اساس فرضیات ما هستند.حالتی را فرض کنید که با متخصصین دامنه در آغاز پروژه جلسه ای را برگزار می کنید. آنها تلاش می کنند تا مشکل خود را به شما شرح دهند و شما آرام آرام شروع به شناخت زبان آنها می کنید و پس از مدتی فکر می کنید که ایده اصلی آن ها را دریافت نموده و کم و بیش متوجه شده اید که چه کاری باید انجام دهید. در اینجا مهم است که بحث مربوط به سوگیری های شناختی و تاثیر گذاری آنها در تصمیم گیری که در فصل قبل اشاره شد را به یاد آورید. اولین و مهمترین ریسک در اینجا، این ریسک است: چیزی که می بینید، تمام چیزی است که وجود دارد. (ریسک دسترسی اکتشافی). شما دانش محدود خود را که از تجربیات گذشته تان نشات گرفته است را به کار می گیرید، سپس احساس می کنید کامل متوجه شده اید. در این نقطه معمولا از ما خواسته می شود که تخمین بزنیم و منطقا تخمین درستی نمی زنیم، چرا که سوگیری ها با ذهن ما بازی کرده و به ما توهم درک موضوع را داده اند.در چنین جلساتی، ما غالبا بر روی چیزی توافق می کنیم. سپس جلسه را ترک می کنیم. شاید پس از چند هفته مجددا در مورد مشخصات و حتی پروتوتایپ ها نیز صحبت کنیم. زمان گذر می کند و ما هنوز در همان اتاق هستیم که بودیم. هیچ کس راضی نیست. متوجه می شویم که ما بر روی یک چیز کاملا متفاوت توافق کرده بودیم. هر کسی تصویری در ذهن داشت که این تصویر ها باهم متفاوت بودند.اگر تصویرسازی نکنیم، روی چیزهای مختلف توافق می کنیمافراد ساعت ها صرف بحث کردن در مورد چیزهایی می کنند که فکر می کنند متفاوت هستند، اما در واقع یکی هستند. همچنین در مورد چیزی توافق می کنند که درک مشترکی درباره آن ندارند. این توافقات هیچوقت خوب پیش نمی روند. برای حل این مشکل، باید فرضیات را کنار گذاریم. باید چیزهای ضمنی (Implicit) را صریح (Explicit) کنیم.به نمونه زیر بعنوان یک سیستم مدیریت منابع انسانی واقعی نگاه کنید. در این فرم یک کارمند می تواند درخواست مرخصی کند.فرم ثبت مرخصیما در اینجا یک ساختار متداول را می بینیم که توسط یک برنامه نویس ایجاد شده است. همچنین می توانیم تصور کنیم که یک جدول SQL وجود دارد که دیتاهای وارد شده در این فرم را ذخیره سازی می کند. این جدول احتمالا ستون های StartDate، EndDate، HalfDay و Id کارمند را دارد. دقت کنید که یک دکمه Save هم داریم که در فرم هایی شبیه به این بسیار متداول هستند.با وجود اینکه این فرم کاملا درست به نظر می رسد، بیایید کمی در آن عمیق تر شویم:فیلد Start Date دارای ابهام است. آیا اشاره به زمانی دارد که فرم ثبت نام پر شده است یا زمانی است که کارمند بدلیل بیماری سر کار حاظر نشده است؟فیلد End Date ابهام بیشتری هم دارد. آیا این تاریخ آخرین روزی است که مرخصی گرفته شده است یا اولین روزی است که کارمند به محل کار باز گشته است؟فیلد Half Day می تواند برای هر کدام از دو تاریخ بالا اعمال شود. اما مشخص نشده است که برای کدام روز اتخاذ شده است.در نهایت، دکمه Save به ما هیچ نشانه ای از این که بعد از آن چه اتفاقی رخ خواهد داد، نداده است. ممکن است که فقط یک رکورد در دیتابیس افزوده شود و نیاز باشد بریم به کسی بگوئیم که برود آن را نگاه کند. یا ممکن است یک فرایند تایید مرخصی وجود داشته باشد که پس از فشردن Save به سرعت آغاز شود. آیا کارمند نیاز دارد تا بعد از ثبت فرم مرخصی، با ایمیل یا تلفن مدیر خط را در جریان بگذارد؟همانطور که می بینید، حتی در یک فرم کوچک با دو فیلد و یک چک باکس و دو دکمه، بسیاری از موارد ضمنی هستند. اگر کد پشت این فرم را تصور کنیم، تمام این ابهامات آن جا نیز نمایان خواهد شد. قبلا در مورد جدول احتمالی و ستون های آن جدول که نشان دهنده فیلدهای فرم هستند، صحبت نمودیم. تمامی خصوصیات موجود در کلاس های مدل دامین، آبجکت های دیتا مدل و سایر کدهای مرتبط با این فرم، همگی مبهم و ضمنی خواهند بود. همه چیز آنجا نیازمند یک توضیح هست. مانند اینکه "این تاریخ نشان دهنده زمانی است که کارمند به محل کار باز میگردد".حالا فرم بالا را با فرم زیر مقایسه کنید:فرم ثبت مرخصی که منطقی تر به نظر می رسددر این فرم، فیلد ها برای افراد معمولی که نیاز به حل معما یا خوانش راهنما برای پر کردن آن ها ندارند، منطقی تر به نظر می رسد. چیزهایی که در فرم قبل ضمنی بودند، اکنون صریح شده اند. همه چیز، از نام گذاری فیلدها تا دکمه ها (call to action)، معانی بهتری پیدا کردند. همچنین می توانیم تخمین بزنیم پشت این فرم، کدی شبیه به این وجود دارد: https://gist.github.com/msadeqshajari/322edaf592e1f0ce05027bd855b3b51b این کد بیانگر معانی و اصطلاحات مشترک با رابط کاربری است. بنابراین، نه تنها کاربر نهایی براحتی می تواند این فرم را تکمیل کند، بلکه یک رفیق برنامه نویس هم با خوشحالی می تواند این کد را بخواند، چرا که هدف به وضوح بیان شده است و تمامی مفاهیم، صریح هستند.جنبه دیگر صریح سازی ضمنی ها، ایجاد مفاهیم دامین است که در کد قابل رویت است. در کد بالا، دستور SendSickLeaveForApproval بیانگر مفهوم دامین دقیقی در کد است. صادق شجری صادق شجری Sat, 20 Jul 2024 10:55:39 +0330 https://virgool.io/software-development/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-domain-driven-design-%D8%B2%D8%A8%D8%A7%D9%86-%D9%85%D8%B4%D8%AA%D8%B1%DA%A9-%D9%88-%D9%81%D8%B1%D8%A7%DA%AF%DB%8C%D8%B1-tigsuaxkmu5e اتفاقی نیست که اریک ایوانز نویسنده اصلی کتاب DDD، آدرس سایتش را domainlanguage.com انتخاب کرده است. مفاهیم پایه ای DDD مانند زبان فراگیر (Ubiquitous Language) و مرزبندی زمینه ها (Bounded Context) بر اساس ایده زبان ایجاد شده اند. ممکن است این مساله برای برنامه نویسان تازه کار عجیب به نظر برسد. چرا که از نگاه آنها، تنها زبان با اهمیت، زبان برنامه نویسی است. ما فرض می کنیم که ترجمه زبان انسان ها به یک زبان برنامه نویسی، عصاره کار ماست. در حالیکه تا حدودی این مطلب صحیح است اما با بخش حیاتی کار روزانه ما بعنوان توسعه دهندگان نرم افزار فاصله دارد.دو نفر فقط در صورتی می توانند یکدیگر را درک کنند که بتوانند به یک زبان مشترک باهم سخن بگویند. لازم نیست این فهم مشترک حتما از طریق زبانی رخ دهد. ممکن است از طریق زبان اشاره یا حتی موسیقی به خوبی شکل گیرد. اما در هر صورت، نیاز است که درک مشترکی از روش ارتباطی با یکدیگر داشته باشند. در غیر این صورت، مشکل بوجود می آید. نه تنها آنها نیاز دارند تا با یک زبان مشترک باهم صحبت کنند، بلکه نیاز دارند تا در زمینه (context) آن زبان نیز مشترک باشند. برای مثال انگلستان و امریکا، هر دو به یک زبان صحبت می کنند. اما بعلت تفاوت زمینه ها ممکن است از یک جمله مختلف در این دو کشور دو برداشت متفاوت صورت گیرد.زبان دامینتقریبا هر صنعتی، زبان خاص به خود را توسعه داده است به گونه ای که فقط افراد داخل آن صنعت بطور کامل آن را درک می کنند. بعضی از کلمات آن زبان ها به کل جهان گسترش یافته اند، مانند دنیای خودرو که زبان ما را با اصطلاحاتی مثل گیربکس یا مثلا فروشگاه لوازم یدکی غنی تر کرده است. اصطلاح فروشگاه لوازم یدکی را اگر در بیرون از دامین خودرو نگاه کنیم، ممکن است دچار ابهام شویم. اما به محض اینکه دامین مشخص می شود، مبرهن می شود که منظور ما مثلا لوازم یدکی برای لوله کشی نیست، بلکه جایی است که ابزار مورد نیاز داخل خودرو در آن خرید و فروش می شود.مثال دیگری از صنعت های دیگر، صنعت نرم افزار است. زمانی که دو برنامه نویس در مورد پیاده سازی جزئیات یک سیستم پیچیده صحبت می کنند، افراد غیر برنامه نویس اطراف آنها چیزی از صحبت آن دو نفر دستگیرشان نمی شود و معمولا بحثی کسل کننده به نظرشان می رسد. عدم درک و شناخت همیشه باعث عدم علاقه و جذابیت می شود.دنیا از نگاه یک برنامه نویسصنعت نرم افزار را می توان از منظری، یک صنعت خاص در نظر گرفت. چرا که تلاشش این است که به رفع مشکل صنعت های مختلف کمک کند. امروزه تقریبا همه چیز نیاز یا تمایل به سطحی از اتوماسیون و نرم افزار دارد. این مورد همچنین بدین معنی است که افراد در کسب و کارهای مختلف، سراغ برنامه نویس های خود یا شرکت های نرم افزاری دیگر می روند و تلاش می کنند تا مشکل خود را به آنها به زبان خودشان عرضه نمایند. زمانی که این زبان به درستی درک نشود، مشکلات آغاز می شود.نیازمندی های فنی نوشته شده توسط متخصصینی که نه افرادی در آن صنعت هستند و نه برنامه نویس هستند، دیده شده که بعنوان چاهی برای نرم افزار های موفق عمل می کنند که در آن گرفتار می شوند. هربار که یک خروجی ناخوشایند به یک مشتری ناراضی می دهیم، نیازمندی ها را سرزنش می کنیم. پس از آن به مشتری می گوییم که نیازمندی ها را بهتر می نویسیم و تلاش می کنیم که جزئیات بیشتری را بررسی کنیم و به برنامه نویسان بابت هر جزئیات کوچکی نیز توضیحات کامل ارائه کنیم. این روند به سرعت باعث می شود که هر کس انگشت اتهام را به سمت شخص دیگری اشاره بگیرد و هیچ کس بابت هیچ چیز مسئولیت نخواهد پذیرفت.همانطور که در بخش اول گفته شد، لیست نیازمندی ها نه تنها فقط بر روی راه حل بجای مساله تمرکز دارند، بلکه تلاش دارند که زبان کسب و کار را به یک زبان فنی تر ترجمه کنند، بطوری که خوشایند برنامه نویسان باشد. در واقعیت، این کار بیشتر شبیه به یک تلفن شکسته است. سطوح بیشتری از ترجمه که به خطوط انتقالی اضافه شود، دیتای مرتبط کمتری به دریافت کننده می رسد.یکی دیگر از اثرات این ترجمه، کند نمودن سرعت ارتباط است. اگر برنامه نویسان به جزئیات بیشتری از کسب و کار نیاز داشته باشند، آنهم بدون اینکه خود کسب و کار را درک کرده باشند، درگیر شدن مترجم اجتناب ناپذیر خواهد شد. زیاد شنیده می شود که شخص مشخصی مانند معمار نرم افزار فقط اجازه صحبت با مشتری را دارد. سپس آنها نیازمندی های نرم افزار را به تحلیل گران کسب و کار می دهند و آنها این نیازمندی ها را به برنامه نویسان بیچاره واگذار می کنند! که عملا در این فرایند ترجمه گم شده اند.به همین خاطر است که درک کسب و کار، برای افرادی که برای ساخت یک راه حل خوب برای یک مشکل واقعی کسب و کار فعالیت دارند، الزامی می شود. درک کسب و کار و ارتباط با آن بدون نیاز به مترجم، نه تنها زمان ارتباط را کاهش می دهد، بلکه کیفیت این چنین ارتباطی را نیز به شدت افزایش می دهد.همزمان، همه می دانیم که دسترسی به افراد حاظر در یک کسب و کار که معمولا نقش مشتریان را برای ما ایفا می کنند، کار راحتی نیست. ممکن است نهایتا چند جلسه بتوانید با آنها برگزار کنید و اطلاعات حیاتی مورد نیاز برای دستیابی به ساخت یک سیستم که نیاز آنهاست را بدست آورید. در این حالت، وجود یک شخص خاص که مورد اعتماد کسب و کار است و به زبان آن ها صحبت می کند، بسیار کمک کننده است. باید اطمینان حاصل کنیم که این شخص همچنین برای تیم توسعه نیز مورد اعتماد است. این شخص را می توانید تحلیل گر کسب و کار یا مالک محصول صدا بزنید که اهمیت خاصی ندارد. مهم این است که این شخص قادر باشد با هر کسی به زبان خودشان صحبت کند، مانند یک مترجم سطح بالا که صحبت های یک رئیس جمهور را طوری ترجمه می کند که معنی کلمات و عبارات در ترجمه ضایع نشود. باز، هنوز هم بهترین رویکرد عدم وجود مترجم بین تیم توسعه و کسب و کار می باشد!مثلا بانکدار های شهر لندن، همیشه بدنبال توسعه دهندگانی هستند که قبلا از خدمات بانکی زیاد استفاده کرده باشند و همینطور در این شهر زندگی کرده باشند. آنها برای وقتشان ارزش قائلند و بدنبال کوتاه کردن زمان ارتباطات و مذاکرات هستند. پس شخصی که به زبان آنها آشنا باشد و به درک خوبی از کسب و کارشان رسیده باشد، برای آنها نسبت به کسی که برنامه نویس بهتر و با سابقه تری باشد، ارجحیت دارد.دامین نمونه یک اپلیکیشندر طول این دوره، ما یک اپلیکیشن نمونه را به منظور بکارگیری دانش و مهارت هایمان توسعه می دهیم. در این بخش، یک مقدمه برای شناخت دامنه کسب و کار گفته میشود، سپس در ادامه مباحث، جزئیات بیشتری در مورد دامین کسب و کار افزوده خواهد شد.دامینی که قصد داریم روی آن کار کنیم، یک سیستم فروش لوازم آنلاین برای اشخاص حقیقی است. ما اپلیکیشنی خواهیم ساخت که تبلیغات دسته بندی شده را منتشر کند بعلاوه چیزی که ممکن است برای پشتیبانی از این نوع فعالیت مورد نیاز باشد.اگر با اصطلاح های گفته شده خو نگرفتید، فرض کنید مجموعه ای از لوازم (شاید خرت و پرت!) که در انباری خانه تان دارید که ممکن است مایل به حتی دور ریختن آنها باشید. شما می توانید یک تبلیغ کوچک گذارید و افراد دیگر ممکن است به چیزی که شما نیاز ندارید، نیاز داشته باشند و آن را بخرند. حتی می توانید آنها را به رایگان به دیگران بدهید. سرویس های مشابهی مانند eBay وجود دارد. یا برای ما ایرانیها، کاری است که دقیقا پلتفرم هایی مانند دیوار و شیپور انجام می دهند.در بخش های بعدی، در جزئیات این دامین بیشتر غرق می شویم و به آهستگی و با درک مفاهیم و دانش های جدید نسبت به ساخت و توسعه آن اقدام می کنیم. صادق شجری صادق شجری Thu, 18 Jul 2024 18:36:50 +0330 https://virgool.io/software-development/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-domain-driven-design-%D8%AF%D8%A7%D9%86%D8%A7%DB%8C%DB%8C-%D8%AF%D8%B1-%D8%A8%D8%B1%D8%A7%D8%A8%D8%B1-%D8%AC%D9%87%D8%A7%D9%84%D8%AA-ybt3cndp7t2u بیشتر برنامه نویسان تازه کار، فرض می کنند توسعه نرم افزار فقط تایپ کد است و زمانی که تجربه بیشتری در تایپ کردن کد بدست می آورند و با کلیدهای میانبر بیشتری از IDE آشنا می شوند و فریمورک ها و کتابخانه ها را بهتر درک می کنند، تصور می کنند تبدیل به توسعه دهندگان نینجا شده اند و می توانند نرم افزاری مانند اینستاگرام را در چندین روز بنویسند!اما واقعیت کاملا متفاوت است. پس از کسب مقداری تجربه و بعد از گذران چندین ماه یا حتی سال که ددلاین های غیر ممکن و اهداف غیر واقع بینانه را می بینند، افراد شروع به کم کردن سرعتشان می کنند. افراد شروع به درک این موضوع می کنند که نوشتن سریع کد بعد از دریافت یک مساله جدید احتمالا بهترین ایده نیست. غرق شدن در راه حل بجای درک صحیح مساله، بی اعتنایی به پیچیدگی های ضروری و اعمال سوگیری های شناختی، همه این فاکتورها در زمان توسعه نرم افزار تاثیر می گذارند. به محض کسب تجربه بیشتر و فراگیری از اشتباهات گذشته خودمان یا دیگران، خواهیم آموخت که ضروری ترین بخش نوشتن کد مفید و نرم افزار سودمند، دانایی در مورد فضای مساله ای (problem space) است که برای آن در حال ایجاد یک راه حل هستیم.دانایی در مورد دامینهمه دانش ها به یک اندازه در زمان ساخت یک فرایند نرم افزاری مهم و موثر نیستند. دانستن چگونگی کدنویسی با جاوا در دامین های مالی ممکن است تاثیر چندانی در نوشتن اپ iOS برای مدیریت بنگاه املاک نداشته باشد. البته قواعدی مانند clean code، DRY و ... با هر زبان برنامه نویسی که کار کنید، قطعا مفید خواهد بود. اما دانایی در مورد یک دامین ممکن است کاملا با نیازمندی های شما برای یک دامین دیگر متفاوت باشد.اینجا، جایی است که ما مفهوم دانایی دامین را مطرح می کنیم. دانایی دامین، دانش در مورد آن دامینی است که می خواهید نرم افزارتان را در آن اجرا کنید. اگر در حال ساخت یک سیستم خرید و فروش باشید، دامین شما دامین مالی خرید و فروش است. پس نیاز دارید تا در مورد خرید و فروش مقداری دانش بدست بیاورید تا متوجه حرف هایی که کاربران با شما یا با یکدیگر می زنند یا نیازهایی که مطرح می کنند، بشوید.تمام این موارد در فضای مساله هستند. اگر قادر نباشید تا حداقل اصطلاح فضای مساله را درک کنید، صحبت با کاربران آینده شما سخت یا غیرممکن خواهد بود. اگر مشکل عدم شناخت دامنه را داشته باشید، تنها منبع اطلاعاتی شما لیست خصوصیات سیستم (specification list) خواهد بود. اما در صورت شناخت دامین، یکی از اثرات، ایجاد اعتماد بین کاربر و برنامه نویس خواهد بود. وقتی این اعتماد ایجاد می شود، برنامه نویس بینش بهتری از مساله دریافت می کند و اشتباهاتش آسانتر بخشیده می گردد. با صحبت در مورد دامین با متخصصین دامین (domain experts) (کاربران سیستم یا مشتریان)، همچنین اعتبار دریافت می کنید و آنها به شما بعنوان همکار نگاه می کنند.دستیابی به این دانش، کار آسانی نیست. افراد در دامین های خودشان با گذر زمان زیادی متخصص شده اند و آنها توسط این تخصص گذران زندگی می کنند. توسعه دهندگان نرم افزار یا آنالیزورهای کسب و کار، کار دیگری انجام می دهند و آن دامین مشخص ممکن است برای آنها کم شناخته شده باشد یا بطور کامل ناشناخته باشد. هنر اصلی در دستیابی به دانش دامین از طریق همکاری موثر می باشد. متخصصین دامنه، منبع بی نهایت اعتماد در آن دامنه هستند. با این وجود، آنها ممکن است اینطور نباشند! برخی از سازمان ها، دانش را قطعه بندی می کنند و ممکن است تکه هایی از اطلاعات مورد انتظار شما در هر بخش از سازمان باشد که وظیفه شما دیدن همان تکه هاست.توصیه کلی در اینجا، صحبت با تعداد زیادی از افراد در داخل دامین است. از مدیریت کل مجموعه گرفته تا دامین های زیر مجموعه. در زیر تعدادی از راهها برای دستیابی به این دانش اشاره شده است:صحبت کردن، محبوب ترین روش است که می تواند در قالب جلسات متعدد باشد. با این وجود، این صحبت ها ممکن است در صورتی که خروجی واضحی نداشته باشد، شما را به بیراهه ببرد. اما هنوز هم در همین صحبت ها ارزش هایی از دامین نهفته است. نیاز دارید تا به دقت گوش دهید و سوالات زیادی بپرسید تا این ارزش ها نمایان شوند.مشاهده نیز یک تکنیک بسیار قدرتمند است. افراد حوزه نرم افزار نیاز دارند تا با درونگرایی خود مقابله کنند، از برج امنیت خود بیرون بیایند و به طبقه خرید و فروش، انبار، لابی هتل یا هرجایی که کسب و کار در آن فعال است وارد شوند. سپس با مردم صحبت کنند و ببینند آنها چگونه کار می کنند.داستان سرایی در مورد دامین، تکنیکی است که توسط گرف ها، فلش ها و مقدار کمی متن همراه با شمارش به ترتیبت عملیات بوجود می آید تا تعاملات مختلف داخل دامین را تشریح کند. این روش، معمولا آسان بوده و نیاز به توضیح فراوانی برای افراد مختلف درگیر در پروژه ندارد.طوفان فکری. طوفان فکری از یادداشت کن و یک رول کاغذ تشکیل می شود که تمام فعالیت های موجود در دامین را به شکلی متناسب مدل سازی می کند. این روش اجازه می دهد تا فعالیت ها، جریان های کاری، فرایندهای کسب و کار و... را کشف کنید. اغلب، این روش همچنین باعث در معرض قرار گرفتن ابهامات، فرضیات، اصطلاحات نامشهود، سردرگمی ها و بعضی وقت ها تداخلات و ناراحتی ها می گردد. به طور خلاصه، هر چیزی که در دانش دامین وجود دارد! در بخش های بعدی به طور مفصل در مورد این روش صحبت خواهیم کرد.پرهیز از جهالت...فیلیپ آرمور مقاله ای در سال 2000 با نام 5 سطح جهالت (five orders of ignorance) منتشر کرد. این مقاله نشان می دهد که افزایش دانش دامین و کاهش جهالت در مورد دامین، دو کلید اساسی برای ساخت نرم افزار سودمند است. این مقاله بر روی جهالت از دامین صحبت می کند و 5 سطح از آن را معرفی می کند:سطح صفر جهالت که عدم جهالت است. در این سطح شما هیچ جهالتی نسبت به دامین ندارید و بیشتر دانش در مورد آن چیزی که باید بدانید را دارا هستید. اولین سطح جهالت، عدم دانش است. زمانی رخ می دهد که چیزی نمی دانید اما این ندانستن را قبول کردید و می دانید که نمی دانید. شما می خواهید که دانش بیشتری کسب کنید و جهالت خود را به سطح صفر برسانید، بنابراین کانال هایی برای دستیابی به این دانش در اختیار دارید.دومین سطح، عدم آگاهی است. زمانی که نمی دانید که نمی دانید! غالبا زمانی رخ می دهد که یک لیست خصوصیات دریافت می کنید که راه حل را شرح داده است، بدون اینکه مشخص کند این راه حل تلاش می کند کدام مشکل را رفع کند. این سطح همچنین زمانی دیده می شود که افراد تظاهر به صلاحیت داشتن در مورد مساله ای می کنند که در واقع صلاحیت آن را ندارند، و حتی نسبت به آن بی اطلاع هستند. بسیاری از تصمیمات غلط در این سطح از جهالت رخ می دهد.سطح سوم، عدم پردازش است. در این مرحله، حتی نمی دانید که چگونه باید نسبت به عدم آگاهی خود مطلع شوید. در واقع راهی برای اینکه تشخیص دهید نمی دانید که چه چیزی را نمی دانید، یافت نمی کنید. در این مرحله انجام هر چیزی بسیار مشکل است چرا که ظاهرا هیچ راهی برای دسترسی به کاربران نهایی وجود ندارد. حتی امکان اینکه از آنها بپرسید که درک شما از مساله آنها صحیح هست یا خیر تا بتوانید وارد مرحله عدم آگاهی بشوید نیز وجود ندارد. در این مرحله تقریبا فهم مساله ای که می خواهید آن را حل کنید نیز غیر ممکن است.سطح چهارم، فرا جهالت است. این اتفاق زمانی رخ می دهد که شما چیزی در مورد 5 سطح جهالت نمی دانید!همانطور که می بینید، جهالت در برابر دانایی قرار می گیرد. تنها راه برای کاهش جهالت، افزایش دانایی و درک است. سطح بالای جهالت، چه آگاهانه باشد چه ناآگاهانه، شما را به سمت عدم دانایی و عدم درک مشکل می برد. بنابراین شانس ساخت راه حل اشتباه برای مشکل را بسیار افزایش می دهد.جهالت در مراحل آغازین، در بالاترین سطح قرار می گیرد.اریک ایوانز، پدر DDD، نمودار بالا را بعنوان در بند جهالت بودن تشریح می کند. نکته اینجاست که در شروع هر پروژه ای، ما در وضعیت کمترین دانش و بیشترین جهالت نسبت به آن قرار دایم. در حالیکه بسیاری از تصمیمات مهم درباره طراحی و معماری پروژه نیز در همین مراحل اولیه رخ می دهد. از آنجائی که این تصمیمات بر اساس اصول خاصی گرفته نشده اند، پس مشخصا بهینه ترین نخواهند بود.دن نورث پیش بینی می کند که ما در زمان شروع پروژه، در بهترین حالت، در سطح دوم جهالت قرار داریم. او توصیه می کند که ما تمام تلاش خود را در همان مراحل اولیه برای افزایش دانش نسبت به مساله انجام دهیم. با اینکه احتمال از قلم افتادن موارد زیادی وجود دارد که با پیشرفت پروژه می توان در مورد آنها نیز دانش کسب کرد. این فرایند یادگیری، فرایندی دائمی و تکرار شونده است. صادق شجری صادق شجری Wed, 17 Jul 2024 18:59:32 +0330 https://virgool.io/software-development/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-ddd-%D9%81%D8%B1%D8%A7%DB%8C%D9%86%D8%AF-%D8%AA%D8%B5%D9%85%DB%8C%D9%85-%DA%AF%DB%8C%D8%B1%DB%8C-%D9%88-%D8%B3%D9%88%DA%AF%DB%8C%D8%B1%DB%8C-%D9%87%D8%A7-ftpulneydswk مغز انسان، حجم فراوانی از دیتا را در هر ثانیه پردازش می کند. ما بسیاری از اعمال را بر پایه غریزه و عادت و به طور اصطلاحا auto pilot انجام می دهیم. سایر نواحی فعالیت های مغزی، شامل تفکر، یادگیری و تصمیم گیری می شود. این رخداد ها در مقایسه با auto pilot، به طرز قابل توجهی آهسته تر انجام می شوند و به انرژی بسیار بیشتری نسبت به عملکردهای اتوماتیک انسان نیاز دارند. تئوری فرایند دوگانه در روانشناسی تخمین می زند که این نوع از فعالیت های مغزی کاملا متفاوت پردازش می شوند و دو پروسه متفاوت برای این دو نوع از تفکر وجود دارد. یکی از آنها مخفی است. اتوماتیک و فرایندی ناخودآگاه است. و دیگری پروسه تفکر آگاهانه و خودآگاه است. تفکر ناخوداگاه در طول زمان شکل میگیرد و تغییر آنها بسیار سخت است. چرا که تغییر آن نیازمند توسعه و کار بر روی یک عادت جدید است که کار سهلی نیست. در مقابل، تفکر خودآگاه، می تواند توسط علت یابی های منطقی یا دانش، جایگزین شود و تغییر کند.هر دو این فرایند یا سیستم ها خوشبختانه در یک مغز وجود دارند، اما نحوه عملکرد آنها متفاوت است. تفکر ناخودآگاه را System 1 و خودآگاه را System 2 نیز می گویند:تفاوت های تفکر خودآگاه و ناخودآگاهاما همه اینها چه ارتباطی با DDD دارند؟ نکته مهم در اینجا، چگونگی تصمیم گیری توسط ماست. به طور علمی اثبات شده است که همه انسان ها دارای سوگیری شناختی هستند. بعنوان برنامه نویس، ما راههای خودمان را برای رفع مشکل های فنی داریم و آماده برای کد زدن در زمانی هستیم که چالش های مختلف در بیزینس یک پروژه برای ما بوجود می آید. اما از طرف دیگر، مشتریان ما نیز دارای سوگیری هستند. آنها احتمالا قبلا بدون نرم افزار ما نیز در حال کسب درآمد بوده اند یا ممکن است با استفاده از نرم افزارهای قدیمی 20 سال پیش نیز کار خود را پیش برده باشند. بنابراین ممکن است آنها فقط بدنبال یک روش مدرن یا ابری برای همان مساله باشند که قبلا حل کرده اند. نکته ای که قصد رسیدن به آن را دارم این است که ما باید تلاش کنیم سوگیری های ذهنی خود را تا حد ممکن کاهش دهیم و با ذهنی بازتر به آن چیزی که مشتری نیاز دارد توجه کنیم و در تله سوگیری های خودمان نیافتیم. همین، دلیلی است که گوگل کارگاهی با عنوان سوگیری ناخودآگاه برای کارکنان خود ایجاد می کند تا به تیم خود در آگاه شدن از سوگیری ها و کمک به رفع آن یاری برساند.مدل پیچیدگی Cynefin ما را مجاب می کند که حداقل پیچیدگی هایی که در فضای مساله (و بعضی اوقات در فضای راه حل) وجود دارد را دسته بندی کنیم. اما برای انتخاب دسته بندی مناسب، باید تصمیم گیری های زیادی انجام دهیم که معمولا از ذهن ناخودآگاه و بر اساس سوگیری های شخصی و تجارب گذشته خودمان انجام می شود، بجای اینکه توسط ذهن خودآگاه بوسیله تفکر و منطق شکل بگیرد. شاید همه ما کسانی را بشناسیم که حتی قبل از اینکه مشکل را کامل مطرح کنیم، با گفتن آره، این که انجامش راحته واکنش نشان می دهند.سوگیری های شناختی نقش اساسی اینجا ایفا می کند. برخی از آنها تاثیر عمیقی روی تصمیم گیری ما می گذارد و قطعا در نتیجه تفکر سیستم 1 است. در زیر برخی از سوگیری ها و سرنخ هایی وجود دارد که می تواند در تفکر شما در طراحی سیستم اثرگذار باشد:سوگیری حامی انتخاب: وقتی انتخابی انجام می دهید، حس مثبتی نسبت به آن انتخاب دارید، حتی اگر به شما اثبات شود که این انتخاب نقص های فراوانی دارد. معمولا این حالت در زمان ساخت اولین مدل ایجاد می شود و شخص سعی می کند به هر قیمتی به ادامه آن پافشاری کند، حتی با وجود اینکه ممکن است شواهدی مبنی بر عدم بهینگی این مدل وجود داشته باشد. این سوگیری مثلا زمانی که در حال انتخاب یک دیتابیس یا فریمورک هستید نیز می تواند رخ دهد.سوگیری تاییدی: تقریبا شبیه سوگیری قبلی است. این سوگیری باعث می شود فقط صحبت ها و مشورت هایی که همسو با انتخاب شما است را بشنوید و به مشورت های مخالف یا متضاد بی اعتنایی کنید. حتی اگر به خود شما هم اثبات شود که این مشورت ها صحیح هستند!اثر واگن-باند: وقتی اکثریت حاضر در اتاق روی چیزی توافق کنند، آن چیز شروع به منطقی بودن می کند! بدون درگیر کردن سیستم 2، نظر جمع؛ بدون حتی هیچ دلیل منطقی، اعتبار بیشتری دارد. به یاد داشته باشید که نظر جمع الزاما نظر صحیح نیست!اعتماد به سقف!: زیاد پیش می آید که افراد تمایل به مثبت نگری افراطی نسبت به قابلیت های خودشان داشته باشند. در این صورت ممکن است تصمیم گیری های نادرستی اتخاذ شود که تنها بدلیل نظر خودشان گرفته شده است. یک مثال بارز این سوگیری، فرایند تخمین است. افراد معمولا زمان کمتری را نسبت به واقعیت تا زمان بیشتر برای انجام یک کار تخمین می زنند.دسترسی اکتشافی: اطلاعاتی که ما داریم، الزاما تمام اطلاعات مورد نیاز برای حل یک مساله نیست. افراد تمایل دارند فقط بر اساس اطلاعاتی که دارند، تصمیم اتخاذ نمایند. بدون اینکه در صدد دریافت جزئیات بیشتر در مورد آن مساله باشند. معمولا این سوگیری باعث ساده سازی بیش از حد مساله در دامین شده و در نتیجه تخمین کمتری نسبت به پیچیدگی های ضروری واقعی اتخاذ می گردد. همچنین باعث می شود مثلا یک تکنولوژی برای مساله انتخاب شود، فقط به استناد اینکه همیشه این روش کار کرده است. در نهایت، با این که کار آسانی نیست، همیشه تلاش کنید تا از ذهن خودآگاه (سیستم 2) برای اتخاذ تصمیمات خود استفاده کنید. صادق شجری صادق شجری Sun, 14 Jul 2024 16:37:15 +0330 https://virgool.io/software-development/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-domain-driven-design-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%DA%AF%DB%8C-%D9%87%D8%A7-vcgonq8fnm29 در قسمت قبل، در مورد صنعت نرم افزار و مشکلاتی که از همان آغاز در آن وجود داشتند صحبت کردیم. با فضاهای مساله و راه حل آشنا شدیم و دریافتیم که چگونه ثابت ماندن در اولین راه حل و چکش کاری مداوم آن، باعث می شود تا بدنبال راه حل های دیگر نرویم، درحالیکه ممکن است راه حل های دیگر، بهترین گزینه برای ما باشد.حال قصد داریم در مورد پیچیدگی صحبت کنیم. مفهوم پیچیدگی در دنیای فیزیکی تفاوت چندانی با مفهوم آن در دنیای نرم افزار ندارد. بیشتر نرم افزار ها نوشته می شوند تا با مسائل و مشکلاتی که در دنیای واقعی وجود دارند، سروکار داشته باشند. این مسائل ممکن است در ظاهر ساده به نظر برسند اما در عین حال ذاتا دارای پیچیدگی های خاص خود هستند. بدون شک، پیچیدگی موجود در فضای مساله، در سیستمی که برای حل آن مساله نوشته خواهد شد، تاثیرگذار خواهد بود. تشخیص نوع پیچیدگی که در زمان ساخت نرم افزار با آن درگیر خواهیم بود، اهمیت بسزایی دارد.انواع پیچیدگیدر سال 1986، Fred Brooks مقاله ای نوشت که در آن پیچیدگی را به دو دسته بندی ضروری (essential) و تصادفی (accidental) تقسیم کرد. پیچیدگی ضروری از دامنه می آید. یعنی آنجا که خود مساله وجود دارد (problem space). این نوع پیچیدگی نمی تواند کاهش پیدا کند مگر با کسر بُعد خود مساله. در مقابل، پیچیدگی تصادفی از خود راه حل (solution space)، به راه حل افزوده میشود. این پیچیدگی می تواند شامل یک فریمورک، یک دیتابیس یا زیرساخت های دیگر باشد.سطح پیچیدگی تصادفی با بلوغ هرچه بیشتر صنعت نرم افزار، کاهش می یابد. زبان های برنامه نویسی سطح بالا و ابزارهای مختلفی که وجود دارد، باعث می شود برنامه نویسان وقت بیشتری را صرف فضای مساله (problem space) نمایند. اما همانطور که اشاره شد، اکنون پس از 30 سال، هنوز صنعت درگیر پیچیدگی های تصادفی است. ما ابزارهای قدرتمندی در اختیار داریم اما اکثر این ابزارها، خود نیازمند صرف زمان برای یادگیری هستند. نویسنده اشاره می کند که سالها پیش قطعه کدی به زبان Java Script نوشته بود. وقتی با Angular آشنا شد که چقدر بهتر آن کار را انجام می دهد، به سمت بازنویسی توسط Angular رفت. اما پس از مدتی دریافت که زمان بیشتری در نهایت صرف شد، چرا که یادگیری و چگونگی استفاده از Angular خود یک چالش بزرگ بود.بعنوان مثال دیگر، با وجود کانتینرها، میزبانی و استقرار اپلیکیشن ها ساده تر شد، اما در عین حال به یک Orchestration هم نیاز داریم و پس از مقداری یادگیری جدید، در میابیم که Kubernetes چه کمک بزرگی می تواند به ما کند. اینجاست که درگیر نوشتن YAML می شویم! تمام زمانی که در این مسیر صرف شد، می توانست درگیر نوشتن خود پروژه و حل مساله اصلی شود.غیر ممکن نیست که ما درگیر مسائلی می شویم که از خود فضای مساله نیز پیچیده تر می شوند. معمولا این اتفاق زمانی رخ می دهد که مسائل ما با راه حل های ما مخلوط شوند، یا ما نتوانسته باشیم به درک صحیحی از مساله دست یابیم.رشد پیچیدگی در گذر زمانهمانطور که در نمودار مشخص شده است، در گذر زمان، پیچیدگی های ضروری کاهش می یابند و پیچیدگی های تصادفی افزایش. ممکن است برای شما تعجب برانگیز باشد که با گذر زمان، پیچیدگی های ضروری تقریبا شیب صفر می گیرند (افزوده نمی شوند)، اما پیچیدگی های تصادفی حتی با شیب تندتر از قبل در حال افزوده شدن هستند. چطور این اتفاق رخ می دهد؟ قطعا ما زمان برای افزودن پیچیدگی تصادفی صرف نمی کنیم. زمانی که سیستم به مرور برجسته تر می شود، تلاش های فراوانی انجام می شود و کدهای پشتیبان افزایش می یابند، تا باعث شوند فقط سیستم بعنوان یک کل، کار کند. مثلا سیستم cache را پیاده سازی می کنیم، تلاش می کنیم عملکرد کوئری ها را بهبود دهیم، دیتابیس ها را تفکیک یا مرج می کنیم و ...در نهایت ممکن است ما تصمیم بگیریم پیچیدگی های ضروری را کاهش دهیم تا سیستم بدون مسائل جانبی فراوان، فقط درست کار کند.اما DDD به شما کمک می کند که بر روی مسائل پیچیده ای که در دامین وجود دارد (پیچیدگی های ضروری) تمرکز کنید. قطعا استفاده از ابزار های جدید فرانت اند یا استفاده از یک دیتابیس دایکیومنت کلود جذابیت دارد، اما بدون درک مشکلی که واقعا می خواهیم آن را حل کنیم، ممکن است این موارد فقط اتلاف وقت محسوب شود. DDD چندین تکنیک سودمند برای مدیریت پیچیدگی ها بوسیله تفکیک سیستم به بخش های کوچک تر ارائه می دهد که هر کدام از این بخش ها برای حل مجموعه ای از مشکلات مرتبط ایجاد می شوند. در بخش های آینده این تکنیک ها به تفصیل تشریح خواهند شد.با یک حساب سر انگشتی، اینطور می توان گفت:ضروریات (پیچیدگی های موجود در دامین) را در آغوش بگیرید و پیچیدگی های تصادفی را کاهش دهید. وظیفه شما، افزودن پیچیدگی های تصادفی نیست. در غیر این صورت احتمال افتادن در چاه over-engineering برای شما بالا خواهد رفت. صادق شجری صادق شجری Sat, 13 Jul 2024 14:19:30 +0330 https://virgool.io/software-development/%DA%86%D8%B1%D8%A7-%DA%86%DA%AF%D9%88%D9%86%D9%87-%D9%88-%DA%86%D9%87-%D8%B2%D9%85%D8%A7%D9%86%DB%8C-%D8%A7%D8%B2-domain-driven-design-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%DA%A9%D9%86%DB%8C%D9%85-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-u3jdxx3gxms7 پیشینه آغاز صنعت نرم افزار، به اوایل دهه 1960 میلادی باز میگردد و از آن زمان همیشه در حال پیشرفت و توسعه بوده است. اما از همان اولین سالها، پروژه هایی که دیر به نتیجه می رسیدند یا هزینه های هنگفتی برای تکمیل نیاز داشتند، بعلاوه پروژه های شکست خورده، تعداد بسیار بالایی را به خود اختصاص می دادند و این روند هم اکنون نیز ادامه دارد.بر اساس گزارشی که در سال 2015 منتشر شده است، پیش بینی شده است که بین سالهای 2011 تا 2015، فقط 22% از پروژه ها با موفقیت به سرانجام رسیده اند. 19% از پروژه ها کاملا شکست خورده اند و مابقی پروژه ها با چالش های مخصوص به خود در حال کشمکش و مبارزه هستند.در طول 4 دهه، بسیاری از روش های مدیریت پروژه های نرم افزاری ایجاد شدند و توسعه یافتند، اما یا بی اثر بودند یا تاثیر چندانی روی بهبود درصد پروژه های موفق نگذاشتند.یکی از فاکتورهای حیاتی موثر در موفقیت پروژه ها، شناخت مساله واقعی و تلاش به رفع آن است. منظور از مساله، آن مشکل یا موضوعی است که بخاطر آن، شما یا کارفرما به توسعه یک نرم افزار احساس نیاز کردید و فکر می کنید این نرم افزار قرار است مشکل معین و واضح پیش بینی شده را رفع کند. این مشکل (شناخت مساله)، دقیقا نقطه ای است که Domain Driven Design در صدد رفع آن است. این اصطلاح اولین بار در سال 2004 توسط Eric Evans در کتاب مشهور Domain-Driven Design: Tackling Complexity in the Heart of Software، به کار برده و تشریح شد. اصلی ترین عامل اقبال عمومی به این مفهوم این است که DDD تشریح می کند که افراد در صنعت IT چگونه می توانند به یک درک صحیح و جامع از نیازهای کاربران دست یابند تا بتواننند نرم افزارهایی توسعه دهند که مشکلات آنها را رفع کند و برای آنها تاثیر گذار باشد.شناخت مسالهما کد نمی نویسیم تا کد زده باشیم! ما پروژه ها را انجام می دهیم تا به دیگران کمک کنیم کارشان را سریع تر، بهتر و بهینه تر انجام دهند. بدون وجود مشکلی که باید حل شود، نوشتن پروژه کاری عبث است. از نگاه روانشانسی شناختی، مشکل عبارت است از فاصله وضعیت کنونی تا وضعیت دلخواه و ایده آل.فضای مساله و فضای راه حل (Problem Space و Solution Space)بشریت، مسائل و مشکلاتش را بوسلیه جستجو برای یک راه حل در فضای مساله برطرف می سازد. این فضا، بیانگر حالت های اولیه (initial state) و وضعیت ایده آل(desired state) است، همانطور که وضعیت های میانه ای نیز وجود دارد. این تئوری توسط Allen Newel و Herbert Simon مطرح شد. همچنین این فضا شامل قواعد و شاخصه هایی است که زمینه مساله را تعریف می سازد.در صنعت نرم افزار، افرادی که درگیر مساله هستند، معمولا مشتریان و کاربران هستند.برای هر مساله، راه حلی وجود دارد. اگر بدرستی در فضای مساله جستجو کنیم، متوجه قدمهای مورد نیاز برای گذار از حالت اولیه به حالت ایده آل خواهیم شد. این فضا را فضای راه حل می گویند.داستان رایجی که برای تعریف این دو فضا استفاده می شود، داستان نوشتن در فضاست. در دهه 1960، دانشمندان به مساله ای برخوردند که خودکارهای رایج در فضا به علت تفاوت های جاذبه، قابل استفاده نیستند. ناسا چندین میلیون دلار هزینه کرد تا خودکاری متناسب با این شرایط ابداع کند، اما شوروی برای رفع این مشکل، بجای خودکار، از مداد استفاده کرد و بدون صرف زمان و هزینه مشکل را رفع کرد!اصلا کمیاب و عجیب نیست که تفسیرهای ما از مشکلات موجود در دنیای واقعی اشتباه باشد. به گونه ای که پیچیدگی های غیر لازمی را برای رسیدن به راه حل می افزائیم و سپس مجبور می شویم مشکلاتی را رفع کنیم که اصلا وجود نداشتند!البته ناسا بعد از این ماجرا شروع به استفاده از مداد کرد اما بعد بخاطر مشکلاتی از قبیل تولید ریزگردها، شکستن نوک مدادها و احتمال آتش گرفتن مداد بخاطر جنس چوبی آن، استفاده از مداد را متوقف کرد. بعدها یک شرکت خصوصی به نام Fisher نوع خاصی از خودکار را برای استفاده در خلاء توسعه داد و ناسا پس از آزمایش آن، تصمیم به استفاده از آن گرفت. این خودکار سپس مورد توجه شوروی قرار گرفت و به مرور در سرتاسر جهان مشتریانی پیدا کرد. قیمت این خودکار برای همه یکسان و 2.39 دلار بود.در اینجا شما بُعد دیگری از مساله فضای مشکل/راه حل را می بینید. اگرچه در ظاهر، مساله ساده به نظر می رسید، محدودیت های جدیدی پدیدار شد که بعنوان نیازمندی های عملیاتی، باعث شد راه حل، پیچیده تر از چیزی که در ابتدا به نظر می رسید شود.پریدن به سمت راه حل بسیار آسان است. مخصوصا برای ما که تجربه فراوانی در حل مشکلات در کدها یا حرفه خود داریم. تفکر در مورد راه حل، مانع از تفکر مغز ما در مورد خود مشکل می شود. بجای تفکر در مورد مشکل، ما در راه حلی که در ابتدا به ذهنمان خطور کرده غرق می شویم که باعث ایجاد مراتب بیشتری از جزئیات می شود و در نهایت به این نتیجه می رسیم که راه حل ما بهترین راه حل ممکن برای حل آن مشکل معین است.پس جنبه دیگری که در جستجوی راه حل برای مساله بوجود می آید، خطر ثابت ماندن (قفلی زدن!) در اولین راه حلی است که به ذهنمان خطور کرده. این راه حل معمولا صرفا بدلیل تجارب شخصی ما در حل مشکلات قبلی توسط مغز ما انتخاب شده است، نه به این خاطر که بهترین راه حل ممکن است!پالایش در مقایسه با اکتشافرویکرد اکتشافی، شامل جستجو و انتخاب راه حل های مختلف، مستلزم کار فراوان و امتحان راههای مختلف است، بجای اینکه روی بهبود متوالی یک ایده خوب متمرکز شود (پالایش). اما راه حلی که توسط این اکتشاف بدست می آید، احتمال دقیق تر بودن و ارزشمندتر بودن بیشتری دارد.نیازمندی ها، چه مشکلی با ما دارند؟!معمولا توسعه دهندگان ارتباط کمی با کسی که بدنبال حل واقعی مشکلش هست دارند. معمولا افراد دیگری مانند تحلیل گرها، آنالیزر های کسب و کار یا مدیر پروژه ها با مشتریان صحبت می کنند و خروجی مکالماتشان را در قالب نیازمندی های فنی و عملیاتی در اختیار تیم توسعه دهنده قرار می دهند. این نیازمندی ها به اشکال گوناگونی در اختیار توسعه دهندگان قرار می گیرند. یا به صورت یک دایکیومنت بلند بالا به نام سند مشخصات مورد نیاز (requirements specifications) یا بصورت منعطف تر (agile) در قالب یوزر استوری ها.مثال زیر را در نظر بگیرید:هر روز، سیستم باید برای هر هتل، یک لیست از مهمان هایی که انتظار می رود در آن روز ورود و خروج کنند، تولید کند.همانطور که می بینید، این عبارت فقط راه حل را شرح می دهد. ما درکی از این نداریم که کاربر در حال انجام چه کاری است و چه مشکلی را سیستم ما باید رفع کند. نیازمندی های اضافی مورد نیاز نیز باید مشخص شده، سپس راه حل باید پالایش شود. اما شرحی از خود مساله هیچوقت در مشخصات مورد نیاز نیامده است.در مقابل، توسط یوزر استوری ها، بینش بیشتری در مورد آنچه کاربران نیاز دارند بدست می آوریم. بیایید یک یوزر استوری واقعی در زندگی را مرور کنیم:بعنوان یک مدیر انبارداری، میخواهم قادر باشم یک گزارش در سطح انبار دریافت کنم تا بتوانم محصولاتی را که موجودی آنها نزدیک به صفر هست را مجددا سفارش دهم.اکنون ما این بینش را داریم که کاربر چه گزارشی نیاز دارد. اما این یوزر استوری در واقع به توسعه دهنده دیکته می کند که باید چه کاری انجام دهد یا ندهد. پس این یوزر استوری نیز مستقیم به راه حل اشاره می کند. در حالیکه احتمالا مساله اصلی کاربر، نیاز به یک فرایند هوشمند تر برای جلوگیری از کاهش موجودی انبارها می باشد. یا شاید کاربر به دنبال یک سیستم پیشرفته پیش بینی خرید است که بتواند بدون ذخیره سازی اضافه، زمان سفارشات بعدی خود را بداند.اصلا به این فکر نکنید که صرف زمان برای درک نیازمندی های کاربر، کاری عبث و اتلاف وقت است. شناخت این نیازمندی ها که تقریبا همیشه بیانگر درکی درست از مشکل واقعی از زاویه دید کاربر است، امری حیاتی است. عدم درک مشکل واقعی کاربر، باعث صرف زمان و هزینه بیشتر و بیشتر و شاید ایجاد فیچرهایی با کیفیت بالا می شود، اما شاید در جهتی متفاوت از رفع مشکل واقعی کاربر!روش های agile و lean مشوق خوبی برای ارتباط مستقیم و بیشتر بین توسعه دهندگان و کاربران نهایی هستند. درک مشترک مسائل بین همه سهامداران، توسعه دهندگان و کاربران نهایی و تست کنندگان، یافتن راه حل ها به کمک یکدیگر، از بین بردن فرضیات غلط و ساخت پروتوتایپ هایی برای کاربران نهایی، همه این موارد می تواند منتج به دستیابی به یک تیم موفق و در نتیجه یک پروژه موفق می گردد. در بخش بعدی خواهیم دید که این مفاهیم ارتباط نزدیکی با DDD دارند! صادق شجری صادق شجری Fri, 21 Jun 2024 20:05:56 +0330 https://virgool.io/@msadeqshajari/%D9%85%D9%82%D8%A7%DB%8C%D8%B3%D9%87-graphql-%D9%88-restful-lntz0xfzavdc در دهه گذشته، REST تبدیل به یک استاندارد پرطرفدار برای طراحی API شده است. REST دارای ویژگی های عالی ای مانند stateless بودن و دسترسی ساختارمند می باشد. با این وجود، REST نشان داد که در برابر نیازهای جدید و تغییر یافته کلاینت هایی که به آن API دسترسی دارند، انعطاف پذیری کافی را ندارد.اما GraphQL به منظور کارامدی و انعطاف پذیری بالاتر طراحی شده است. GraphQL بسیاری از کاستی ها و ناکارامدی های REST را برطرف کرده است.اگر در مورد GraphQL آشنایی لازم را ندارید، این مقاله را بخوانید.به منظور نشان دادن تفاوت های اصلی بین REST و GraphQL یک سناریوی ساده را در نظر می گیریم. فرض کنید یک وبلاگ داریم و نیاز داریم تا عناوین پست های منتشر شده توسط یک کار معین را دریافت کنیم. در همان صفحه، می خواهیم نام آخرین 3 نفری که فرد را فالو کرده اند، ببینیم. این مسائل چگونه با هر کدام از روش های REST یا GraphQL حل می شوند؟دریافت دیتا توسط GraphQL و RESTبا REST معمولا این مساله با صدا زدن چند endpoint حل می شود. در این مثال، مثلا اندپوینت users/id را صدا می زنیم تا اطلاعات اولیه در مورد کاربر را دریافت کنیم. سپس باید اندپوینتی شبیه به users/<id>/posts را صدا بزنیم تا تمامی پست های کاربر را دریافت کنیم. در نهایت، اندپوینتی شبیه به users/<id>/followers را صدا می زنیم که لیستی از فالوورهای کاربر را برمیگرداند:همانطور که در تصویر بالا مشاهده می کنید، برای سناریوی ما، سه بار صدا زدن api مورد نیاز است. اما در GraphQL براحتی می توانید یک کوئری به سرور GraphQL ارسال کنید که نیازهای دیتایتان را بطور کامل در بر بگیرد. سپس سرور پاسخ را به شکل json به شما بازخواهد گرداند:یکی از اصلی ترین مشکلاتی که REST دارد، رخ دادن overfetching و underfetching در زمان صدا زدن اندپوینت ها می باشد. چرا که تنها راه برای کلاینت بمنظور دانلود دیتا، صدا زدن endpoint هایی است که ساختار دیتای ثابتی برمیگردانند. طراحی api ای که بتواند دقیقا نیازهای کلاینت را برگرداند، کار بسیار سختی است.به گراف فکر کنید، نه به اندپوینت هااما overfetching بدین معنی است که یک کلاینت مجبور است اطلاعات بیشتر از نیاز اپ را دانلود کند. برای مثال یک صفحه را در تصور کنید که نیاز به نمایش لیستی از تنها نام کاربران دارد. در یک REST API، اپ معمولا اندپوینت users را صدا می زند و یک آرایه جیسون همراه با دیتای یوزرها بازمیگرداند. این پاسخ ممکن است دیتای اضافه ای برای هر کاربر را نیز بازگرداند. مثلا آدرس و نام خانوادگی آنها را در حالی که نیازی به آنها نیست.مشکل دیگر underfetching است. این مشکل به معنای این است که یک endpoint اطلاعات مورد نیاز و کافی را ممکن است به شما بازنگرداند. در این حالت کلاینت مجبور است تا request های دیگری را هم بدهد تا تمام دیتای مورد نظرش را دریافت کند. مثلا فرض کنید یک کلاینت مجبور است در ابتدا لیستی از المنت ها را دریافت کند و سپس برای هر کدام از آیتم های لیست، request جداگانه ای بزند تا دیتاهای دیگر را در مورد آن دریافت کند.حلقه های پرسرعت توسعه اپ در فرانت اندیک الگوی متداول با REST، ساختار بخشی به اندپوینت ها بر اساس ویو هایی است که باید در اپ تان داشته باشید. این روش، مناسب است چرا که به کلاینت اجازه می دهد تمامی اطلاعات مورد نیاز برای یک ویو خاص را با صدا زدن اندپوینت مدنظر دریافت کند.اصلی ترین نقص این رویکرد، این است که حلقه ساخت پرسرعت برای فرانت را غیر ممکن می کند. با هر تغییری که در UI حاصل می شود، این ریسک وجود دارد که اکنون دیتای کمتر یا بیشتری نیاز است. پس بک اند نیاز دارد تا اندپوینت مورد نظر را با توجه به UI جدید، تغییر دهد. این امر، بهره وری را کاهش میدهد و سرعت توسعه را پایین میاورد.با GraphQL این مشکل مرتفع شده است. با تشکر از طبیعت منعطف GraphQL، تغییرات در سمت کلاینت می تواند بدون کار اضافی از سمت سرور انجام شود. چرا که کلاینت ها می توانند دیتایی را که نیاز دارند مشخص کنند و به توسعه دهنده بک اند نیاز نیست تا بر مبنای تغییرات دیزاین، تغییراتی روی کد های بک اند انجام دهد.آمارهای مفید در سمت بک اندگرف کیو ال این امکان را در اختیار شما می گذارد تا به آمار و بینشی مناسب از دیتاهای درخواست شده در بک اند دست یابید. چون هر کلاینت مشخص می کند که دقیقا به چه اطلاعاتی نیاز دارد و علاقمند هست، دستیابی به فهم چگونگی استفاده از دیتا امکان پذیر است. مثلا می توانید به کمک api های صدا زده شده، فیلد های بلااستفاده را شناسایی کنید.با GraphQL، همچنین می توانید مانیتورینگ سطح پایین را برای request ها انجام دهید. GraphQL از مفهوم resolver function ها به منظور جمع آوری دیتای درخواست شده توسط کلاینت استفاده می کند.منافع سیستم Type و Schemaدر GraphQL از یک سیستم قدرتمند type به منظور تعریف قابلیت های api استفاده می شود. تمامی type های اعلان شده در یک API در یک schema توسط زبان GraphQL Schema Definition (SDL) تعریف می شود.این schema بعنوان یک قرارداد بین کلاینت و سرور بمنظور تعیین چگونگی دسترسی کلاینت به دیتا خدمت می کند.بمحض اینکه schema تعریف شد، تیم هایی که روی بک اند یا فرانت اند کار می کنند می توانند کارشان را بدون برقراری ارتباط های بعدی بینشان انجام دهند چرا که هر دوی آنها ساختار تعریف شده دیتای ارسالی توسط سرور را می دانند.تیم های فرانت اند براحتی می توانند اپ هایشان را با ساختارهای دیتای تستی (mock) تست کنند. بمحض اینکه سرور آماده شد، تغییر به production برای اپ های کلاینت بدون دردسر و براحتی انجام می شود. صادق شجری صادق شجری Wed, 28 Jul 2021 19:39:06 +0430 https://virgool.io/@msadeqshajari/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-graphql-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-mlgbm57jr9wb نکته: این مقاله تنها به معرفی GraphQL می پردازد و به چگونگی پیاده سازی یا استفاده از آن پرداخته نشده است. در بخش های دیگر، آموزش های عملیاتی نیز اضافه خواهد شد.گرف کیو ال (GraphQL) استاندارد جدیدی برای ساخت API است که نسبت به REST، کارآمد تر، قدرتمند تر و منعطف تر است.این استاندارد API توسط Facebook توسعه داده شده و همچنین open source می باشد. امروزه، جامعه ای با فراوانی بزرگی از شرکت ها و افراد، از آن استفاده می کنند.امروزه، API ها به عناصر فراگیری از زیرساخت های صنعت نرم افزار تبدیل شده اند. بطور خلاصه، یک API مشخص می کند که چگونه کلاینت می تواند دیتا را از یک سرور دریافت کند.هسته GraphQL، از declarative data fetching استفاده می کند. جایی که کلاینت می تواند مشخص کند که دقیقا به چه دیتایی از یک API نیاز دارد. بجای اینکه چندین اندپوینت وجود داشته باشد که هر کدام دیتای ثابتی را بازگردانند، یک سرور GraphQL تنها یک اندپوینت ارائه می دهد که با توجه به دیتای مشخصی که کلاینت درخواست می دهد، پاسخ را بر اساس همان درخواست، باز می گرداند.گرف کیو ال، یک زبان کوئری برای API هاستبرای روشن شدن این موضوع، SQL را در نظر بگیرید. SQL یک زبان استاندارد برای کوئری گرفتن دیتا از دیتابیس های relational است و این استاندارد در تمامی آنها، رعایت شده و کارایی دارد.حال، GraphQL هم یک زبان استاندارد برای کوئری گرفتن از API هاست! امروزه بسیاری از اپلیکیشن ها، نیاز به دریافت دیتا از سروری دارند که آن دیتاها معمولا در دیتابیس ها ذخیره سازی می شوند. وظیفه API، ایجاد رابط و مسیری بین دیتاهای ذخیره شده در دیتابیس و نیازهای اپلیکیشن است. GraphQL یک زبان کوئری برای API هاست، نه دیتابیس ها. با این فرض، می توانید از GraphQL در هر کجا که مفهومی به نام API وجود دارد استفاده کنید.گرف کیو ال، جایگزینی کارآمد تر از REST استدر مقاله ای جداگانه به تفسیر و تفصیل علل برتری GraphQL نسبت به REST می پردازیم. همانطور که می دانید، REST روشی پر طرفدار برای دریافت دیتا از سرور است. اوایلی که مفهوم REST پرکاربرد شد، اپلیکیشن های کلاینت، ساده تر شدند و بسیاری از اپ ها از طریق آن توانستند به خوبی با سرور ارتباط برقرار کرده و تبادل دیتا کنند. اما در سال های اخیر، زمینه های استفاده از API تغییرات فراوانی داشت. به طور کلی، سه فاکتور وجود داشت که روش طراحی API توسط REST را به چالش کشید:1- افزایش استفاده از موبایل، نیاز به بارگزاری کارامد دیتا را بیشتر کردافزایش استفاده از موبایل، دستگاههای موبایل با سخت افزار های سبک و توان پایین، و شبکه های اینترنت کم سرعت، دلایل اولیه ای بودند که باعت شد Facebook اقدام به توسعه GraphQL کند. GraphQL حجم دیتایی که نیاز است در شبکه منتقل شود را به حداقل می رساند و باعث می شود دستگاههایی که درگیر دو مورد گفته شده بودند، بهترین عملکرد را داشته باشند.2- تنوع فریمورک ها و پلتفرم های سمت فرانت اندمنظره ناهمگونی که از پلتفرم ها و فریمورک های فرانت اند برای اجرای اپ های کلاینت وجود دارد، ساخت و نگهداری یک API که پاسخگوی تمام نیازها باشد را سخت می کند. از طریق GraphQL، هر کلاینت می تواند دقیقا به دیتاهایی که نیاز دارد، دست پیدا کند.3- توسعه پرسرعت و انتظارات برای توسعه سریع feature هااستقرار مداوم (continuous deployment) تبدیل به استاندارد برای بسیاری از شرکت ها شده است. چرخه توسعه سریع و بروزرسانی های پشت سر هم، به امری ضروری تبدیل شده است. با REST API ها، روشی که دیتا توسط سرور بازگردانده می شود، معمولا نیاز به دستکاری دارد تا با نیازهای خاص و تغییرات طراحی در سمت کلاینت منطبق باشد. این امر باعث کاهش سرعت توسعه و در نتیجه استقرار اپ می شود.گرف کیو ال تنها برای توسعه دهندگان react نیست...فیس بوک، برای اولین بار در سال 2012 از GraphQL در اپ های موبایل نیتیو خود استفاده کرد. جالب است بدانید که در آن زمان، GraphQL بیشتر برای تکنولوژی های وب استفاده می شد و تنها بخش کوچکی از آن در اپ های موبایل استفاده می شد.اولین باری که فیس بوک، در عموم حرفی از GraphQL به میان آورد، در کنفرانس React.js در سال 2015 بود که در همان کنفرانس، مسیر اوپن سورس شدن آن نیز مشخص شد. از آنجائیکه فیس بوک همیشه از GraphQL در زمینه react صحبت می کرد، مدتی طول کشید تا سایر توسعه دهندگان در مورد GraphQL بیاموزند که این تکنولوژی محصور به react نیست.جامعه ای که به سرعت در حال رشد استدر واقع، GraphQL تکنولوژی ای است که می تواند همه جا برای ارتباط بین کلاینت و API استفاده شود. سایر شرکت ها مانند Netflix یا Coursera روی ایده هایی مشابه و مقایسه ای کار کردند تا ارتباط با API را کارامد تر کنند. اما بعد از اینکه GraphQL اوپن سورس شد، این شرکت ها به طور کامل پروژه هایشان را تعطیل کرده و سوار قطار GraphQL شدند!امروزه، GraphQL در بسیاری از شرکت ها چون Github، Twitter، Yelp و Shopify در حال استفاده است. صادق شجری صادق شجری Tue, 27 Jul 2021 15:29:30 +0430 https://virgool.io/@msadeqshajari/%D8%B1%D9%88%DB%8C%D8%A7%DB%8C-%D9%85%D9%88%D9%84%D8%AA%DB%8C-%D9%BE%D9%84%D8%AA%D9%81%D8%B1%D9%85-%D8%AF%D8%B1-%D8%AF%D8%A7%D8%AA-%D9%86%D8%AA-%D8%A8%D8%A7-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-uno-platform-hz1px7phencw در دنیای مدرن مهندسی کامپیوتر و نرم افزار، یکی از برجسته ترین بحث ها، بحث توسعه کد نویسی در مولتی پلتفرم می باشد. بدین معنی که یک بار کد بزنید (UI و Backend) و بتوانید در قالب چندین پلتفرم از آن خروجی بگیرید. برای مثال، از کد واحد خود، خروجی apk برای اندروید، ipa برای iOS، خروجی لینوکس، مک، ویندوز، و حتی وب سایت بگیرید! هیجان انگیزه نه؟اما این خواسته، دور از ذهن و در سطح رویای دوردست نیست. بلکه صنعت نرم افزار به سرعت به این سمت در حال حرکت است. برای مثال، کاتلین قدم های خوبی در این مسیر برداشته و بعید نیست امسال در سال 2021 نسخه ای پایدار از مولتی پلتفرم خود را ارائه دهد.فریمورک دات نت نیز از این داستان مثتثنی نیست و در صدد است هرچه زودتر و قوی تر به این مهم دست یابد. شاید Uno Platform نسخه ای رسمی از دات نت و مایکروسافت نباشد، اما تیم فعالی که روی این پلتفرم در حال کار هستند، همگی از تیم مایکروسافت و توسعه دات نت هستند. پس می شود منتظر اعلام رسمی چیزی شبیه به Uno بود!احتمالا تا کنون به میزان کافی مشتاق جزئیات و معرفی Uno Platform شده اید. اول از همه از سایتشان در این آدرس بازدید کنید. بسیار خوب به معرفی این پلتفرم ساخته همراه با اسناد و مثال های مختلف که شاید نیاز شما به مطالعه ادامه این متن را مرتفع کند! اما در ادامه تلاش کردم به زبانی آسوده و روندی مناسب، هم مفاهیم را مطرح کنم و هم مثال کوچکی در این زمینه بزنم.Pixel-Perfect Multi-Platform Applications for Windows, macOS, Linux, Android, iOS, WebAssembly with C# and WinUIجمله بالا، تیتر اول سایت Uno می باشد. عبارت Pixel Perfect به این مورد اشاره دارد که در هنگام خروجی گرفتن به هر پلتفرمی، کیفیت پیکسل ها کاهش پیدا نخواهد کرد و کاربر احساس بدی در UI پیدا نخواهد کرد.خروجی Uno برای وب سایت، Blazor آن هم از نوع WebAssembly است. اگر با Blazor آشنا نیستید و خروجی وب سایت برای شما جذاب است، حتما تا همینجا متن را نگه داشته و بعد از مطالعه در مورد آن، برگشته و ادامه متن را مطالعه کنید!در عنوان سایت آمده که : توسط سی شارپ و WinUI. سی شارپ که مشخص است. اما WinUI را برای کسانی که آشنایی ندارند، تعریف می کنم:آینده ساخت نرم افزار ها و برگ برنده تکنولوژی هایی چون WinForms و WPF و UWP، استفاده از WinUI است. WinUI اکوسیستمی شامل تعداد زیاد و کاملی از کنترل هایی است که می توانید در نرم افزارهای ویندوزی از آن استفاده کنید. همچنین می توانید از این کنترل های مدرن و جامع، در پلتفرم های غیر ویندوزی مانند اندروید و iOS استفاده کنید. (مثلا با استفاده از Uno Platform). می توانید لیستی از این کنترل ها را از اینجا ببینید. ورود به جزئیات WinUI، ما را از بحث اصلی دور می کند. اما با مثالی کوچک، استفاده از این کنترل ها را نشان می دهم.فرض کنید در نرم افزار Uno خودمان نیاز به کنترلی برای انتخاب تاریخ داریم. می توانیم بدین شکل این کنترل را به اپلیکیشن مان اضافه کنیم:<DatePicker x:Name=&quotbirthDatePicker&quot Header=&quotDate of birth&quot/>خروجی این کد، تصویر زیر است:با استفاده از پلتفرم Uno می توانید رابط کاربری خود را در XAML و با استفاده از کنترل های UWP و یا WinUI طراحی کنید. و در حالت بهینه، با معماری MVVM، رفتارها و بطور کلی Business Logic را پیاده سازی کنید. سپس اپ UWP خود را در ویژوال استودیو اجرا کنید. همه چی درست بود؟ بسیار خوب. اپ های سایر پلتفرم ها نیز آماده است! به همین سادگی!زمان آن رسیده که با مثالی عملی، چگونگی این کار را به شما نشان دهم. برای توسعه در این پلتفرم به ویژوال استودیو 2019 نیاز داریم. دقت کنید که باید ابزارهای زیر در ویژوال استودیو نصب باشد. در غیر این صورت از منوی Tools و سپس Get tools and features اقدام به نصب این موارد کنید:به ویژوال استودیو بازگشته، از منوی Extensions گزینه Manage Extensions را انتخاب کرده و برای Uno جستجو کنید. از نتایج حاصله، Uno Platform Solution Templates را انتخاب کنید:پس از نصب، به صفحه ایجاد پروژه ای جدید وارد شوید و عبارت Uno را جستجو کنید. از لیست موجود، گزینه Cross Platform App (Uno Platform) را انتخاب کنید.نامی برای پروژه انتخاب و آن را ایجاد کنید. همانطور که در Solution Explorer می بینید، پروژه های مختلفی برای شما ایجاد شد. وارد پروژه ای که نام YourProjectName.Shared دارد شده و MainPage.XAML را انتخاب کنید.در MainPage.XAML عبارات زیر را وارد کنید:<StackPanel Background=&quot{ThemeResource ApplicationPageBackgroundThemeBrush}&quot Margin=&quot15&quot> <Slider x:Name=&quotslider&quot/> <TextBlock Text=&quot{Binding ElementName=slider, Path=Value}&quot/></StackPanel>ما یک اسلایدر داریم و با Binding می خواهیم که مقدار آن را در متن زیر آن نمایش دهیم.حال پروژه را در حالت UWP اجرا می کنیم. خروجی زیر را می بینیم:همین پروژه را در حالت اندروید تست می کنیم:و همینطور در حالت وب سایت (WASM):نتیجه گیری: با پلتفرم تازه نفس Uno آشنا شدیم و متوجه شدیم که اگر این پروژه پیشرفت کند و کامل تر از این هم بشود، تحولی شگرف در صنعت مهندسی نرم افزار رقم خواهد زد. در صورتی که سوالی برای شما پیش آمده یا به مشکلی بر خوردید حتما با من در میان بگذارید. ارادتمند شما صادق شجری صادق شجری Fri, 05 Mar 2021 19:14:44 +0330 https://virgool.io/@msadeqshajari/%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-pipeline-%D9%87%D8%A7%DB%8C-azure-%D8%A7%D8%B5%D9%88%D9%84-%D9%88-%D9%85%D9%81%D8%A7%D9%87%DB%8C%D9%85-%DA%A9%D9%84%DB%8C%D8%AF%DB%8C-2-n3ms4oraaumz نکته: قبل از شروع مطالعه قسمت دوم، قسمت اول را مشاهده کنید: https://virgool.io/@msadeqshajary/%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-pipeline-%D9%87%D8%A7%DB%8C-azure-%D9%82%D8%B3%D9%85%D8%AA-1-usttbrvxjhce درک صحیح اصطلاحات بکار رفته و شناخت بخش های Azure Pipelines در استفاده صحیح و اصولی از این ابزار مفید یاری دهنده خواهد بود.در ابتدا به تصویر زیر دقت کنید: یک trigger به پایپ لاین دستور اجرا می دهد.یک پایپ لاین از یک یا چندین stage ساخته شده است. یک پایپ لاین می تواند در یک یا چند محیط مستقر شود.یک stage، راهی برای سازماندهی job ها در یک پایپ لاین است. هر stage می تواند یک یا چندین job داشته باشد.هر job بر روی یک agent اجرا می شود. همچنین یک job می تواند بدون agent باشد.هر agent یک job را شروع می کند که شامل یک یا چند step است.یک step می تواند یک task یا یک script باشد که این دو، کوچکترین ساختار موجود در پایپ لاین هستند.یک task در واقع یک script از قبل پکیج شده است که یک عمل خاص را اجرا می کند. مانند فراخوانی یک REST API یا انتشار یک build artifact.یک artifact مجموعه ای از فایلها یا پکیج هایی است که توسط یک run منتشر می شوند.مفهوم Agentزمانی که Build یا deployment اجرا شد، سیستم یک یا چند job را آغاز می کند. یک Agent در حال محاسبه زیرساخت مورد نیاز (از طریق نصب نرم افزاری که یک job را در هر بار، اجرا می کند) است.مفهوم Approvalsمجموعه ای از اعتبارسنجی های مورد نیاز یک توزیع را تعریف میکند. approval دستی یک بررسی معمولی است که برای کنترل توزیع ها (deployments) در محیط های production اجرا می شود. زمانی که این بررسی ها در یک محیط پیکربندی شد، پایپ لاین ها تا زمان بررسی موفقیت آمیز همه چک ها،قبل از شروع یک stage متوقف می شود.مفهوم deployment groupsیک deployment group مجموعه ای از ماشین های مقصد deployment است که دارای agent های نصب شده هستند. می توان گفت یک deployment group تنها گروهی از agent هاست. شما می توانید مجموعه ای از مقاصد deployment را در یک پایپ لاین برای یک job با استفاده از deployment group ها تنظیم کنید.مفهوم Enviornmentیک Environment (محیط) مجموعه ای از منابع است که می توانید اپلیکیشن خود را در آنجا مستقر کنید. این محیط می تواند شامل یک یا چند ماشین مجازی یا Container ها یا Web App ها یا مجموعه ای از سرویس ها باشد که شما برای میزبانی اپلیکیشنی که در حال توسعه هستید، به آنها نیاز دارید. یک پایپ لاین ممکن است اپ را در یک یا چند محیط بعد از اینکهbuild انجام شد، مستقر گرداند و تست ها را در آنجا روی اپ انجام دهد.مفهوم Jobیک stage شامل یک یا چندین job است. هر job الزاما در یک agent اجرا می شود. یک job نشان دهنده چگونگی اجرای مجموعه ای از step هاست. تمامی step ها باهم و بر روی agent یکسان اجرا می شوند. برای مثال، ممکن است دو پیکربندی ایجاد کنید، x86 و x64. در این حالت، شما یک build stage و دو job دارید.مفهوم Runیک run نشان دهنده یک بار اجرای یک پایپ لاین است. لاگ های مرتبط با اجرای step ها و نتایج تست های اجرا شده را جمع آوری می کند. در زمان Run، پایپ لاین های Azure در ابتدا پایپ لاین را تحلیل می کنند و سپس عملیات run را به یک یا چندین agent اعمال می کنند. هر agent باید job ها را run کند.مفهوم Scriptیک اسکریپت، کدها را بعنوان یک step در پایپ لاین شما از طریق command line اجرا می کند.مفهوم Stageیک stage مرزبندی منطقی در پایپ لاین را نشان می دهد. می توان از آن برای متمایز کردن موارد استفاده کرد (مانند Build، QA، و Production). هر stage شامل یک یا چند job است.مفهوم Stepیک step کوچکترین واحد یک پایپ لاین است. برای مثال یک پایپ لاین ممکن است شامل step های build و test باشد. همچنین می تواند یک script یا task باشد. یک task تنها یک script از پیش ایجاد شده است که برای راحتی شما بوجود آمده. برای مشاهده task های آماده به لینک زیر مراجعه کنید: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/?view=azure-devops مفهوم Triggerیک Trigger به پایپ لاین می گوید که چه زمانی اجرا شود؟ می توانید اینگونه پیکربندی کنید که پایپ لاین به محض push شدن کدها به ریپازیتوری اجرا شود، یا در زمان های مشخص اجرا شود و ... .در ادامه و در مقاله بعدی به ایجاد عملی یک پایپ لاین در ریپازیتوی Azure میپردازیم. صادق شجری صادق شجری Sat, 05 Sep 2020 18:03:40 +0430 https://virgool.io/@msadeqshajari/%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-pipeline-%D9%87%D8%A7%DB%8C-azure-%D9%82%D8%B3%D9%85%D8%AA-1-usttbrvxjhce اگر با مفاهیم CI/CD و پایپ لاین آشنایی ندارید، ابتدا مقاله زیر را مطالعه فرمائید: https://vrgl.ir/oyKzm پایپ لاین Azure چیست؟پایپ لاین های مایکروسافت Azure، سرویس های ابری ای هستند که می توانید برای build و test خودکار پروژه های خود استفاده کرده و آنها را برای سایر کاربران در دسترس قرار دهید. این روش برای تمامی زبان های برنامه نویسی و هر نوعی از پروژه قابل اجراست.پایپ لاین های Azure ادغام مداوم (CI) و تحویل مداوم (CD) را با یکدیگر به منظور test و build مداوم و مطمئن کدهای شما ترکیب کرده و می تواند به هر محیط توسعه هدفی برساند.سیستم های ورژن کنترلقبل از اینکه بخواهید از CI/CD برای اپ های خود استفاده کنید، باید کد های سورس خود را در یک سیستم ورژن کنترل قرار دهید. پایپ لاین های Azure با سرویس های Github، Azure Repos Git & TFVC، Bitbucket Cloud و ... سازگاری دارد.مقصد های توزیعاز Azure Pipelines برای استقرار کدهایتان در چندین مقصد می توانید استفاده کنید. این مقاصد می تواند شامل container registries، virtual machines، Azure Services یا هر مقصد تحت کلود دیگری باشد.پیش نیاز های استفاده از پایپ لاین های Azureبرای استفاده از Azure Pipelines نیاز دارید تا:یک شرکت(اکانت) در Azure DevOps تعریف کنید.کدهای سورس خود را در یک سیستم ورژن کنترل نگهداری کنید.برای تعریف پایپ لاین ها در Azure از سینتکس YAML و یا از رابط های کاربری کلاسیک استفاده می شود.ادغام مداوم (CI)، test و build های خودکار را برای پروژه شما انجام می دهد. CI به شما کمک می کند تا باگ ها را به سرعت و در چرخه توسعه بیابید (نه در زمان توزیع اپ). خروجی تولید شده توسط سیستم های CI را مصنوعات (artifacts) می گویند که مورد استفاده CD می باشد. CD پس از دریافت از CI، بصورت خودکار کدها را در چندین stage مستقر کرده و تست می کند.پس بطور خلاصه می توان اینطور گفت که سیستم های CI تولید کننده artifact های قابل استقرار هستند که شامل زیرساخت ها و اپ ها می شوند. سپس این artifact ها بصورت خودکار توسط پایپ لاین های انتشار، مصرف شده و نسخه های جدیدی را بر روی مقاصد انتخابی شما ایجاد می کنند.1- تعریف پایپ لاین ها توسط سینتکس YAMLپایپ لاین هایتان را از طریق یک فایل YAML به نام azure-pipelines.yml در کنار سایر فایل های پروژه تعریف می کنید.پایپ لاین شما همراه با کدهایتان ورژن داده می شوند. آنها از ساختار مشابهی با branch ها بهره می برند. تغییرات ایجاد شده در کد را مانند قبل، از طریق بازبینی در pull request ها بررسی می کنید.می توانید در هر برنچ (شاخه)، قواعد build را با اصلاح فایل azure-pipelines.yml تغییر دهید.هر تغییری در فرایند build (مرحله قبل) می تواند مسبب شکست یا ارور شود. اما از آنجائیکه تغییرات در ورژن کنترل رخ می دهند، می توانید به راحتی مشکل را یافته و آن را حل کنید.این مراحل اساسی را طی کنید:1- پایپ لاین Azure را پیکربندی کنید تا از ریپازیتوری گیت مورد نظر شما استفاده کند.2- فایل azure-pipelines.yml را متناسب با build خود تغییر دهید.3- کدهایتان را به ریپازیتوری ورژن کنترل خودتان push کنید. این عمل باعث خواهد شد که build و استقرار پروژه شما بر اساس قواعد تعریفی تان بصورت خودکار انجام شده و از این پس می توانید نتایج این اقدام را بررسی (monitor) کنید.هم اکنون کد شما بروز رسانی شده، build شده، test شده و پکیج شده است. اکنون می توانید آن را به هر مقصدی توزیع کنید!2- تعریف پایپ لاین ها از طریق رابط کاربری کلاسیکامکان ایجاد و پیکربندی پایپ لاین ها در پورتال وب Azure DevOps با ویرایشگر رابط کاربری کلاسیک نیز وجود دارد. باید یک build pipeline ایجاد کنید تا بتوانید کدهایتان را build و test کنید و سپس artifact ها را منتشر کنید. همچنین یک release pipeline برای مصرف این artifact ها در مقاصد توزیع ایجاد کنید.مراحل اساسی زیر را طی کنید:1- پایپ لاین Azure را پیکربندی کنید تا از ریپوزیتوری گیت شما استفاده کند.2- از ویرایشگر کلاسیک Azure Pipelines بمظور ایجاد و پیکربندی build تان همچنین release pipeline ها استفاده کنید.3- کدهایتان را به ریپازیتوری ورژن کنترلتان push کنید. با این کار، پایپ لاین ایجاد شده از مراحل قبل را فعال کرده و وظایف را (مانند build و test کد) اجرا می کنید.بمحض build، باعث ایجاد artifact هایی می شوید که توسط ادامه pipeline برای اجرای وظایف بعدی (مانند توزیع یا staging یا production) استفاده می شوند.کد شما هم اکنون بروزرسانی شده، build شده، test شده و پکیج شده است. این کد هم اکنون می تواند در هر مقصدی توزیع شود.وضعیت دسترسی به خصوصیاتبرخی از ویژگی های پایپ لاین ها تنها در روش استفاده مستقیم از YAML وجود داشته و برخی دیگر تنها در روش رابط کاربری کلاسیک و یا در هر دو بصورت مشترک وجود دارد. برای مشاهده لیست ویژگی ها و وضعیت پشتیبانی شان توسط هر دو روش به جدول زیر مراجعه کنید: https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started/pipelines-get-started?view=azure-devops#feature-availability صادق شجری صادق شجری Sat, 05 Sep 2020 11:52:21 +0430 https://virgool.io/apieco/%D9%85%D9%81%D8%A7%D9%87%DB%8C%D9%85-cicd-%D9%88-pipeline-%D8%A7%D8%B2-%D8%A7%D8%A8%D8%AA%D8%AF%D8%A7-%D8%AA%D8%A7-%D9%BE%DB%8C%D8%B4%D8%B1%D9%81%D8%AA%D9%87-gq0uabguiu7n به جمله زیر دقت کنید: پایپ لاین CI/CD یکی از بهترین شیوه های پیاده سازی در تیم های devops به منظور دریافت تغییرات ایجاد شده در کد، بصورت مداوم و مطمئن است.در ابتدا، باید قادر باشیم تا مفاهیم اصطلاحات بکار رفته در جمله کلیدی بالا را بطور کامل درک کنیم. بصورت خلاصه برای هر یک از آنها شرح کوتاهی خواهم آورد:1- پایپ لاین (Pipeline)در معنی لغوی و غیر اصطلاحانه، پایپ لاین به لوله های بلندی که معمولا در زیر زمین قرار داشته و برای جابجایی نفت و یا گاز استفاده شده و در متراژ طولانی تعبیه می شوند، گفته می شود. حال به دنیای مهندسی باز می گردیم. پایپ لاین را به توالی خطی ای از ماژول های مشخص می گویند که در جهتی مشخص در حال حرکت هستند.مثلا در دنیای CPU ها، پایپ لاین، به وسیله ای درون CPU گفته می شود که CPU را قادر می سازد دستورات را قبل از اجرا بخواند، و در صورت تایید و به محض تکمیل و بعد از تحویل آن، دستور بعدی را بخواند.2- معنی CI (Continuous Integration)به معنی ادغام مداوم است. یک فلسفه در کدنویسی و مجموعه ای از اقدامات است که تیم های توسعه را به سمت پیاده سازی تغییرات کوچک و بررسی کدها در ریپازیتوری، آنهم بطور مداوم می برد. از آنجایی که اپ های پیشرفته کنونی در چندین پلتفرم و ابزار های مختلف اقدام به توسعه می کنند، لذا نیاز به مکانیزمی برای ادغام (integrate) و تایید (validate) تغییرات مختلف، اهمیت بالاتری پیدا می کند.3- معنی (Continuous Delivery)معنی لغوی آن تحویل مداوم میشود. CD زمانی ظاهر میشود که کار CI به اتمام می رسد. CD عملیات رساندن اپلیکیشن ها به محیط های زیرساختی را بطور اتوماتیک انجام می دهد.4- وظیفه DevOpsوظایف DevOps ترکیبی از عملکردهای توسعه نرم افزار (Dev) و عملیات IT یا(Ops) است که هدف آن کوتاه کردن چرخه عمر سیستم ها و تحویل مداوم (CD) و باکیفیت نرم افزار است.--------------------------اکنون که با اصلاحات مورد نیاز، آشنا تر شدیم و درک بهتری از جمله کلیدی خودمان بدست آوردیم، به شرح بیشتر این موضوع می پردازیم.مفاهیم CI و CD، تجسم یک فرهنگ است. مجموعه ای از قواعد و اقداماتی که تیم های توسعه اپلیکیشن را قادر می سازد تغییرات ایجاد شده در کدها را سریع تر و مطمئن تر بدست مخاطب برساند. پیاده سازی این قواعد و اقدامات را اصطلاحا CI/CD pipeline می گویند.استفاده از CI/CD یکی از بهترین اقداماتی است که تیم های DevOps می توانند انجام دهند. همچنین اقدامی عالی در جهت روش های agile است که تیم های توسعه را قادر میسازد بر روی نیازهای منطقی پروژه، کیفیت کد و همچنین امنیت پروژه تمرکز کنند، چرا که مراحل توزیع پروژه بصورت اتوماتیک انجام می شود.هدف بنیادی CI، دستیابی به راهی اتوماتیک و استوار برای ساخت (Build) ، پکیج (Package) و تست اپلیکیشن ها است. زمانی که فرایند ادغام باثباتی انجام شود، تیم ها راحت تر و با سرعت بالاتری می توانند تغییراتشان را اعمال کنند و باعث بوجود آمدن همکاری بهتر و کیفیت بالاتر نرم افزار می شود.بسیاری از تیم ها از چندین محیط توسعه بجای استفاده تنها از محیط production استفاده می کنند. مانند محیط های development و محیط های testing. و CD اطمینان حاصل می کند که راهی اتوماتیک برای رساندن تغییرات کدها به این محیط ها وجود داشته باشد.ابزارهای CI/CD پارامترهای مختص به هر محیط را ذخیره کرده و سپس هر سرویس مورد نیازی که باید در وب سرور ها، دیتابیس ها و ... استفاده شود را در زمان تحویل، صدا می زند.ادغام مداوم (CI) و تحویل مداوم (CD) نیازمند آزمایش مداوم (continuous testing) است. چرا که هدف، رساندن اپلیکیشن های با کیفیت و کدهای جدید به کاربران است. آزمایش مداوم معمولا بعنوان مجموعه ای از رگرسیون ها و عملکردهای اتوماتیک در پایپ لاین CI/CD انجام می شود.یک CI/CD بالغ و کامل، شامل گزینه پیاده سازی توزیع مداوم است، که تغییرات اپلیکیشن از طریق پایپ لاین CI/CD اجرا شده و build های تایید شده مستقیما در محیط های production توزیع می شوند. تیم هایی که با توزیع مداوم کار می کنند، انتخاب می کنند که با برنامه زمانی روزانه یا حتی ساعتی، به production اپلیکیشن را توزیع کنند، و حتی در برخی از تیم ها، توزیع دائمی، اختیاری نیست و حتما باید بصورت مرتب انجام شود.ادغام مداوم (CI) چگونه کیفیت و کار تیمی را بهبود می بخشد؟زمانی که CI در حال اجراست، توسعه دهندگان بطور مداوم کدهایشان را به ریپوزیتوری ورژن کنترل commit می کنند و اکثر تیم ها این استاندارد را دارند که کدها حداقل روزی یک بار باید commit شوند. بنیاد و پایه پشت این کار این است که شناسایی عیوب و سایر مشکلات کیفی نرم افزار در کدهایی که کمتر تغییر یافته اند، آسان تر است. علاوه بر این، زمانی که توسعه دهندگان روی چرخه عمر کمتری از commit ها کار می کنند، احتمال اینکه یک قطعه کد توسط چندین برنامه نویس بصورت همزمان ویرایش شود، کاهش یافته و نیاز به merge در زمان commit کاهش میابد.تیم هایی که ادغام مداوم را اجرا می کنند، اغلب کارشان را با پیکربندی ورژن کنترل و تعاریف عملیات آغاز می کنند. اگرچه بررسی کدها مداوما و در فواصل زمانی کوتاه انجام می شود، feature ها و رفع عیب ها می توانند در فریم های زمانی کوتاه و بلند پیاده سازی شوند. تیم های توسعه از تکنیک های مختلفی برای کنترل feature ها و کدهایی که آماده برای production هستند، استفاده می کنند.بسیاری از تیم ها از feature flag ها استفاده می کنند. که مکانیزم پیکربندی ای برای فعال سازی feature ها و کد ها در زمان اجرای اپ است. feature هایی که هنوز در حال توسعه هستند، با feature flag در کد مشخص شده و همراه با برنچ master راهی production می شوند. ولی تا زمانی که آماده برای استفاده نباشند، فعال و یا روشن نمی شوند. بر اساس آخرین نظرسنجی، 63 درصد تیم هایی که از feature flag ها استفاده می کنند، testing و کیفیت بالاتر و بهتری از نرم افزار را گزارش داده اند. ابزار feature flagging مانند CloudBees Rollout، Optimizely Rollouts و LaunchDarkly با ابزارهای CI/CD ادغام شده و پیکر بندی های بر پایه feature را ممکن می سازند.یکی دیگر از راههای مدیریت feature ها، استفاده از برنچینگ در ورژن کنترل است. یک استراتژی برنچینگ مانند GitFlow برای تعریف پروتکل هایی است که مثلا در آن مشخص می شود کدهای جدید چگونه باید با برنچ های استاندارد ادغام شده و برای محیط های development یا testing یا production آماده شوند.برنچ های feature دیگری برای آنهایی که زمان توسعه بیشتری نیاز دارند، ایجاد شده و زمانی که feature تکمیل شد، توسعه دهندگان می توانند تغییرات را از این برنچ ها به برنچ ابتدایی برده و ادغام کنند. این رویکرد نیز خوب است، اما مدیریت آنها می تواند مشکل ساز شود، اگر feature های زیادی بطور همزمان در حال توسعه باشند.سپس فرایند build می تواند بوسیله جمع آوری نرم افزار، دیتابیس و اجزای دیگر بطور اتوماتیک انجام شود. فرض کنید اگر در حال توسعه یک اپ جاوا هستید، CI تمامی فایل های استاتیک وب سرور مانند HTML و CSS و جاوا اسکریپت را همراه با اپ جاوا و تمام اسکریپت های دیتابیس جمع آوری می کند.نه تنها CI تمام اجزای نرم افزار و دیتابیس را جمع آوری می کند، بلکه این اتوماسیون می تواند unit test ها و سایر تست ها را بر روی آن انجام دهد. این فرایند تست می تواند به توسعه دهندگان آن کد بازخورد دهد که کدهای جدیدی که نوشته اند، نباید در هیچ unit test شکست بخورد.بسیاری از ابزارهای CI/CD به توسعه دهندگان اجازه می دهد که build ها را بر اساس تقاضا شروع کرده، و آنها را با کدهای commit شده در ورژن کنترل درگیر کند یا می تواند این build در فواصل زمانی مشخصی انجام شود.تست های مداوم، فراتر از تست اتوماتیکفریمورک های تست اتوماتیک، به مهندسان کنترل کیفی کمک می کند که انواع مختلف تست ها را تعریف کرده، اجرا کنند و این کارها را به صورت اتوماتیک انجام دهند که به تیم های توسعه کمک می کند متوجه شوند که آیا build نرم افزار با موفقیت انجام شده است یا خیر؟ اینها شامل تست های عملکردی هستند که در پایان هر Sprint ،توسعه یافته و در تمامی اپ تست می شوند. این تست های رگرسیون، بررسی می کنند که تغییرات کد ایجاد شده توسط تیم در بخشی از نرم افزار شکست خورده یا خیر و آن را در تمام اپلیکیشن که تحت پوشش این تست است، بررسی می کنند. بهترین اقدام، قادرسازی توسعه دهندگان برای اجرای تمام یا بخشی از تست های رگرسیون در محیط توسعه محلی خودشان است. با این کار، این اطمینان حاصل می شود که توسعه دهنده تنها زمانی کدهای خود را commit می کند که تست ها در برابر تغییر کدها، موفقیت آمیز بوده باشند.آزمون regression تنها شروع کار است. تست های عملکردی، تست های API، آنالیز کدهای استاتیک، تست امنیت و سایر اشکال تست نیز می تواند اتوماتیک وار انجام شود. نکته کلیدی، توانایی اجرای این تست ها از طریق command line یا webhook یا وب سرویس ها است و این ها هستند که باید پاسخ مناسب موفقیت آمیز بودن یا عدم موفقیت را به تست کننده برگردانند.به محض اینکه عملیات تست، اتوماتیک شد، تست مداوم دلالت بر این دارد که این اتوماسیون با پایپ لاین CI/CD ادغام می شود. برخی از تست های unit و عملیاتی می توانند با CI در حالی که issue flag دارند؛ ادغام شود. تست هایی که نیاز دارند در محیط نرم افزار کامل انجام شوند، مانند تست های عملکردی یا امنیتی، معمولا باید با CD ادغام شده و بعد از این که build ها به محیط توسعه هدف رسیدند، اجرا شوند.-------------------------پس CI/CD روشی برای تحویل مداوم اپ ها به مشتریان از طریق تعریف اتوماسیون در هر یک از stage های توسعه اپ است. مفاهیم اصلی موجود در CI/CD، ادغام مداوم، تحویل مداوم و توزیع مداوم است. CI/CD راه حل برای مشکلاتی است که در زمان ادغام کدهای جدید برای توسعه دهندگان یا تیم ها بوجود می آید.تفاوت بین CI و CD چیست؟همانطور که گفته شد، CI به ادغام مداوم اشاره دارد که فرایندی اتوماتیک برای توسعه دهندگان است. یک CI موفق، باعث خواهد شد تغییرات جدید در کدها، به صورت منظم Build شده، test شده و با یک ریپازیتوری مشترک merge شود. پس CI می تواند بعنوان راه حلی در برابر وجود تعداد زیاد برنچ ها بصورت همزمان باشد، که این امر امکان تداخل برنچ ها با یکدیگر را کاهش می دهد.اما CD، به تحویل مداوم (continuous delivery) و توزیع مداوم (continuous deployment) اشاره دارد که مفاهیم مرتبط با یکدیگری هستند و برخی اوقات بجای هم استفاده می شوند. اما هر دوی آنها در مورد اتوماتیک سازی stage های پایپ لاین است.تحویل مداوم بدین معناست که تغییرات کدهایی که توسط برنامه نویس بوجود آمده، به صورت خودکار تست باگ شده و در ریپازیتوری آپلود می شود. جایی که این ریپازیتوری ها می توانند در یک محیط production توزیع شوند. در نهایت، هدف تحویل مداوم، حصول اطمینان از کمترین تلاش ممکن برای استقرار کدهای جدید است.توزیع مداوم، اشاره به انتشار خودکار تغییرات برنامه نویس از ریپازیتوری به production دارد، یعنی به جایی که برای مشتریان قابل استفاده است. پس تیم های اجرایی زمان کمتری نسبت به فرایندهای دستی توزیع محصول به کاربران مصرف می کنند.درک اهمیت CI با یک مثالدر دنیای توسعه نرم افزار امروز، هدف، کار همزمان چندین برنامه نویس بر روی feature های مختلف اپ است. حالا فرض کنید سازمان تصمیم گرفته تا تمامی برنچ های ایجاد شده را در یک روز مشخص merge کند. نتیجه این کار، امری طاقت فرسا، دستی و زمانبر خواهد بود. و دلیل آنهم مشخصا این است که برنامه نویس برای توسعه feature تغییراتی را در کد اعمال خواهد کرد که احتمال تداخل با کدهای سایر برنامه نویسان دارد. این مشکل مخصوصا زمانی که هر توسعه دهنده IDE محلی خودش را استفاده کند، بجای اینکه از IDE های کلود استفاده کند، عمیق تر خواهد بود.اما CI به توسعه دهندگان در ادغام کدهایشان با یک برنچ مشترک یاری می دهد. که این ادغام مرتبا یا گاها روزانه و ساعتی خواهد بود. به محض اینکه تغییرات ایجاد شده توسط توسعه دهنده merge شد، بصورت خودکار با build اپ اعتبار سنجی شده و سطوح مختلف تست های اتوماتیک (معمولا unit و تست های ادغام) روی آن صورت می گیرد تا اطمینان حاصل شود که تغییرات صورت گرفته، باعث بهم ریختگی اپ نمی شود. اگر هرگونه تداخل یافت شود، CI کار رفع عیب را آسان تر و سریع تر می کند. صادق شجری صادق شجری Fri, 04 Sep 2020 11:33:48 +0430 https://virgool.io/coderlife/%D8%AA%D8%A7%D8%B1%DB%8C%D8%AE%DA%86%D9%87-%D8%AF%D8%A7%D8%AA-%D9%86%D8%AA-%D9%88-c-p8t6v5bnaqzw دات نت تکنولوژی ای عالی برای ساخت نرم افزار در پلتفرم ویندوز بوده است. اما اکنون، می توان ادعا کرد که NET. تکنولوژی ای عالی برای ساخت نرم افزار در پلتفرم های ویندوز، لینوکس و مک است! ایجاد NET Core. بزرگترین تحولی است که از زمان ایجاد دات نت، رخ داده. اکنون، دات نت Core متن باز (open source) شده، می تواند برای سایر پلتفرم ها نیز اپلیکیشن بسازد و از الگوهای پیشرفته کد نویسی بهره می برد.بازبینی تاریخچه دات نتبرای فهم عمیق تر امکانات در دسترس موجود در دات نت و سی شارپ، دانستن تاریخچه آنها، مفید فایده خواهد بود. جدول زیر، نسخه های مختلف فریمورک دات نت همراه با نسخه CLR و نسخه سی شارپ مرتبط را نمایش می دهد. همچنین نسخه ویژوال استودیویی که در همان سالها منتشر شده است و سازگاری کامل با نسخه دات نت را دارد...نسخه دات نت/نسخه CLR/نسخه سی شارپ/نسخه ویژوال استودیودر تاریخ 27 ژانویه 2016 اولین نسخه از NET Core. رونمایی شد و دومین نسخه از آن در تاریخ 14 آگوست 2017 و در تاریخ سوم دسامبر 2019 نسخه 3.1 منتشر شد. در ادامه به بررسی دقیق تر این مراحل خواهیم پرداخت.سی شارپ 1.0، یک زبان جدیدسی شارپ 1.0، یک زبان برنامه نویسی کاملا جدید بود که برای کار با دات نت فریمورک طراحی و ساخته شد. در زمان ساخت این نسخه، دات نت فریمورک شامل تقریبا 3000 کلاس بود. پس از آنکه مایکروسافت بر اساس حکم دادگاه (که توسط شرکت سان که ایجاد کننده زبان جاوا است، ثبت شده بود)، اجازه پیدا نکرد که تغییراتی در زبان جاوا ایجاد کند، آندرس هلزبرگ، سی شارپ را طراحی کرد. قبل از اینکه او در مایکروسافت مشغول به کار شود، تجربیات موفقی در شرکت Boraland داشت. این شرکت از طراحان زبان دلفی (از گویش های زبان پاسکال) بود. در مایکروسافت، او مسوول ساخت ++J شد (نسخه ی مایکروسافت از جاوا). این امر باعث شد هلزبرگ پیش زمینه هایی برایش ایجاد شود و زبان سی شارپ را که مستقیما تحت تاثیر جاوا و پاسکال و ++C بود را ایجاد کند.بدلیل اینکه سی شارپ بعد از جاوا و ++C ساخته می شد، مایکروسافت مشکلات ایجاد شده در آن زبان ها را بررسی کرد و تغییراتی را داد که از این مشکلات رهایی یابد.امروزه سی شارپ نه تنها یک زبان برنامه نویسی شیء گرای اصیل است، بلکه پیشرفت های مهمی مثلا در زمینه event ها و delegate ها بدست آورده است.کامپایلر دات نت، کدها را به زبان واسطه (IL) تبدیل می کند. CLR نیز شامل کامپایلر JIT است که کدهای ایجاد شده توسط IL را به زبان اصیل ماشین تبدیل کرده و نرم افزار شما اجرا می شود. CLR تنها شامل کامپایلر نیست، بلکه Garbage Collector (GC) را شامل می شود که مسول پاک سازی حافظه از ارجاع هایی است که دیگر مورد نیاز نیستند. از سایر اجزای CLR می توان به مکانیزم امنیتی آن برای بررسی دسترسی کدها و افزونه ای برای دیباگ کردن کد اشاره کرد. همچنین در CLR ابزار تسهیل کار با رشته ها (Threads) نیز وجود دارد که مسوولیت ساخت رشته ها در پلتفرم های اعمال شده را دارد.در نسخه اول دات نت، مجموعه ای شامل 3000 کلاس در namespace های گوناگون وجود داشت که وظیفه namespace ها، تسهیل در مسیریابی این 3000 کلاس موجود با استفاده از گروه بندی کلاس ها در namespace مرتبط خود بود.نسخه اول دات نت امکان ساخت اپلیکیشن های دسکتاپی ویندوز از طریق Windows Form را داشت (System.Windows.Forms namespace). همچنین امکان ساخت اپلیکیشن های وب با استفاده از ASP.NET Web Forms را فراهم کرد. (System.Web). مکانیزم ایجاد رابطه بین اپلیکیشن ها و وب سرویس ها را توسط ASP.NET Web Services و ارتباط آسان تر و سریعتر بین اپلیکیشن های دات نت توسط .NET Remoting را نیز مهیا کرد.تکنولوژی ASP.NET Web Forms امکان ساخت وب اپلیکیشن هایی را داد که هدفش این بود که برنامه نویس نیازی نداشت در مورد HTML و جاوا اسکریپت بداند. کنترل های سمت سرور که شبیه به ویندوز فرم عمل می کردند، خودشان HTML و جاوا اسکریپت مورد نیاز را ایجاد می کردند.سی شارپ 2 و دات نت 2 با Genericsیکی از تغییرات بزرگ در این نسخه استفاده از Generic ها بود. Generic ها امکان ساخت تایپ ها بدون اینکه بدانیم نوع درونی تایپ ها چه هستند را می دهد. نوع درونی تایپ ها در زمان نمونه برداری شان (فراخوانی شان) مشخص می شوند. این مزیت باعث بوجود آمدن نوع های جدیدی در خود فریمورک دات نت شد. برای مثال کلاس های موجود در لیست های Generic با System.Collections.Generics namespace.دات نت 3 - تولد WPFبا انتشار دات نت 3، هیچ نسخه جدیدی از سی شارپ منتشر نشد. دات نت 3 تنها کتابخانه های جدیدی را به خود افزود و تعداد بسیار زیادی از تایپ ها و namespace های جدید را اضافه کرد. WPF احتمالا بزرگ ترین بخش از این فریمورک جدید بود که برای ساخت نرم افزارهای دسکتاپی ویندوزی استفاده می شود. ویندوز فرم از کنترل های اصیل ویندوز بر پایه پیکسل استفاده می کرد در حالیکه WPF بر پایه DirectX بود و از آن برای ترسیم تمامی کنترل های خودش استفاده کرد. وکتورها در WPF با تغییر اندازه کاهش کیفیت نمی دادند و نمونه های موجود در WPF این اجازه را می داد که یک نمای کاملا سفارشی برای نرم افزار ایجاد شود. مثلا فرض کنید یک نرم افزار برای یک شرکت هواپیمایی را که دارای یک دکمه است که به شکل هواپیماست. این امر در ویندوز فرم امکان پذیر نیست و ناگزیر هستید از دکمه های پیش فرض خود ویندوز استفاده کنید. تمامی کلاس های موجود در System.Windows به جز کلاس های System.Windows.Forms متعلق به WPF است. در WPF، رابط کاربری نرم افزار می تواند توسط سینتکس XML طراحی شود: XAML.قبل از دات نت 3، ASP.NET Web Services و .NET Remoting برای ارتباط بین اپلیکیشن ها مجبور به استفاده از چندین API مختلف بودند. در نسخه 3 دات نت این مشکل توسط WCF برطرف شد. WCF تمام گزینه های API ها را با یک API ترکیب کرد.در دات نت 3، تعداد کلاس های فریمورک از 8000 در دات نت 2 به 12000 تایپ، افزایش پیدا کرد.سی شارپ 3 و دات نت 3.5-LINQدات نت 3.5 همزمان با سی شارپ 3 وارد عمل شد. ارتقای اصلی آن ایجاد سینتکسی خاص برای فیلتر و مرتب سازی اشیاء درون لیست ها، فایل های XML و دیتابیس بود. به منظور دسترسی به دیتابیس و ایجاد کوئری، LINQ to SQL ایجاد شده بود. با انتشار اولین آپدیت در دات نت 3.5، Entity Framework منتشر شد. پس از مدتی، ویژگی های موجود در LINQ to SQL با Entity Framework ترکیب شده و امروزه فقط EF وجود دارد. آخرین نسخه آن یعنی EF Core تفاوت های بسیار زیادی با نسخه اولیه آن در دات نت 3.5 دارد.سی شارپ 4 و دات نت 4 - Dynamic و TPLدر این نسخه، به سینتکس سی شارپ عباراتی افزوده شد. شامل کلمه کلیدی dynamic و پارامترهای نام گذاری شده و پارامتر های اختیاری. سایر بهبود ها در داخل دات نت اتفاق افتاد. با گسترس CPU های چند هسته ای، برنامه نویسی موازی اهمیت بالایی پیدا کرد. کتابخانه کارهای موازی - Task Parallel Library(TPL) - با استفاده از رشته ها و کلاس های Parallel و Task، ایجاد کد هایی که به طور موازی اجرا می شدند را آسوده تر کرد.با انتشار نسخه 2010 ویژوال استودیو، تکنولوژی جدیدی برای ایجاد وب اپلیکیشن ها بوجود آمد: ASP.NET MVC 2.0. بر خلاف ASP.NET Web Froms این تکنولوژی بر الگوی Model-View-Controller تمرکز داشت که در ساختار پروژه تاثیرگذار بود. این تکنولوژی همچنین بر کد نویسی HTML و جاوا اسکریپت تمرکز داشت. سی شارپ 5 - برنامه نویسی نابهمگامسی شارپ 5 تنها دو کلمه کلیدی را اضافه کرد: async و await. اما کاری کرد تا نوشتن متدهای نابهمگام بسیار آسان تر شود. با استفاده صحیح از این نوع متد ها، امکان بلاک شدن رشته اصلی از بین می رود و نرم افزار اصطلاحا هنگ نمی کند.از آنجایی که فریمورک System.AddIn بسیار کار را پیچیده و زمان بر می کرد، یک فریمورک ترکیب دیگر به دات نت 4.5 اضافه شد که فریمورک قابلیت مدیریت شده نام گرفت و در System.Composition قرار دارد.نسخه جدیدی از ارتباط بین نرم افزاری که مستقل از زبان برنامه نویسی شان بود به نام ASP.NET Web API ایجاد شد. بر خلاف WCF، از پروتکل بسیار ساده و توانمند REST برای ارتباط بین نرم افزار ها استفاده شد.سی شارپ 6 و دات نت Core 1.0در سی شارپ 6، بهبود اساسی ای که در اکثر نسخه های قبل وجود داشت، رخ نداد اما تعداد زیادی بهبود کوچک و کاربردی که می توانست کدهای نوشته شده را کوتاه و بهینه کند را ایجاد کرد. این بهبود های جدید با کامپایلر جدید Roslyn یا همان NET Compiler. امکان اجرا داشت.با وجود چندین نسخه کوچکتر دات نت (برای مثال Silverlight و Silverlight for Windows Phone)، اشتراک گذاری کد بین نسخه دسکتاپ دات نت و این نسخه های کوچک تر، حائز اهمیت شد. یک تکنولوژی که کدها را بین نسخه های مختلف دات نت به اشتراک می گذاشت، کتابخانه های پرتابل بود. با گذر زمان، با نسخه های فراوانی که از دات نت ایجاد شد، مدیریت کتابخانه پرتابل تبدیل به یک کابوس شد.با وجود این مشکلات، نسخه جدیدی از دات نت اجتناب ناپذیر بود. نسخه جدید از این فریمورک، NET Core. نام گرفت. دات نت Core با پکیج های ماژولار ناگت، کوچک تر از سایر نسخه ها هستند، runtime ای دارند که با تمام اپلیکیشن ها توزیع می شوند، متن باز هستند، و نه تنها برای ویندوز، بلکه برای لینوکس و مک نیز در دسترس هستند.برای ایجاد وب اپ ها، ASP.NET Core 1.0 یک بازنویسی کامل از ASP.NET است. این انتشار با نسخه های قبلی کاملا سازگار نبود لذا ایجاد تغییراتی در کد های کنونی ASP.NET MVC مورد نیاز بود. (با ASP.NET Core MVC). استفاده از این تکنولوژی جدید در وب، مزیت های فراوانی دارد از جمله کاهش سربار درخواست های وب که نتیجه آن عملکرد بالاتر اپ خواهد بود. همچنین، می تواند در سیستم های لینوکسی هم اجرا شود. اما ASP.NET WebForms جزو این انتشار نبود. چرا که از آن برای بهترین عملکرد استفاده نمی شود، بلکه طراحی شده تا توسعه دهندگان آن بر اساس الگوهایی که از Windows Form به خاطر داشتند، به توسعه اپ بپردازند.سی شارپ 7 و دات نت Core نسخه 2سی شارپ 7 خصوصیات جدید متعددی را معرفی کرد. بارزترین آنها در مورد برنامه نویسی functional بود: pattern matching و tuples.اما تمرکز اصلی دات نت Core 2 بر روی تبدیل آسان تر کد های موجود دات نت به دات نت Core بود. تایپ هایی که هنوز برای دات نت Core در دسترس نبودند اما در بسیاری از اپ های کنونی دات نت وجود داشتند، به آن اضافه شدند. بیش از 20000 API به دات نت Core 2 افزوده شد.و NET Standard. ویژگی ای بود که مشخص می کرد کدام API باید در هر پلتفرمی که از Standard پشتیبانی می کرد، وجود داشته باشد. هر چه نسخه استاندارد ارتقا میافت، API های بیشتری در دسترس قرار می گرفت. NET Standard نسخه 2 شامل بیش از 20000 API بود که توسط دات نت 4.6.1 و دات نت Core نسخه 2 و Universal Windows Apps پشتیبانی می شد.برای اینکه بدانید آیا پروژه کنونی شما می تواند به آسانی به دات نت Core تبدیل شود، می توانید از .NET Portability Analyzer استفاده کنید. می توانید این ابزار را از افزونه های ویژوال استودیو دانلود کنید.سی شارپ 8 و دات نت Core نسخه 3برای مطالعه موارد جدید اضافه شده در نسخه 8 سی شارپ، می توانید به صفحه زیر مراجعه کنید: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8 صادق شجری صادق شجری Fri, 28 Aug 2020 17:04:16 +0430