https://virgool.io/feed/@sinadsina78 fa 2026-06-16 15:55:21 https://files.virgool.io/upload/users/146640/avatar/vM0Lo8.jpg?height=120&width=120 https://virgool.io/@sinadsina78 https://virgool.io/@sinadsina78/test-nfavfbdg4vgk ۱-مقدمهبلاکچین ساختار و بستر اصلی توسعه ارزهای دیجیتال موجود در بازارهای مالی دنیا است. از طرفی قابلیت‌های گسترده و جدید این تکنولوژی مانند شبکه غیر متمرکز، تغییر ناپذیری داده، شفافیت و قابلیت حسابرسی تراکنش‌ها باعث شده است تا تراکنش‌های اعمال شده بر پایه این تکنولوژی امن و غیر قابل تغییر باشند از این رو با افزایش آشنایی دنیای توسعه نرم‌افزار با این دست فناوری‌ها، میتوانیم گسترش استفاده از آن را در دیگر حوزه‌ها نیز مانند خدمات اجتماعی و مالی، مدیریت ریسک، خدمات بهداشتی و ... مشاهده کنیم. با این تفاسیر ما در این پژوهش سعی داریم تا در نرم‌افزارهایی که در حال استفاده از این تکنولوژی هستند را بررسی کرده و آن‌ها را در قالب الگو‌های پر تکراری که در روزمره استفاده می‌شوند تا ویژگی‌های کیفی را به حد قابل قبولی برای کاربران برساند، تحلیل و دسته‌بندی کنیم.در ادامه، در ادبیات موضوع مقدمه ای از بلاکچین و معماری نرم افزار گفته می شود. در بخش سوم، مفاهیم مورد توجه و تاثیر گذار در ویژگی های کیفی نرم افزار های مبتنی بر بلاکچین معرفی می شود و الگوهایی برای حل مشکلات و بهبود ویژگی های کیفی به همراه ارتباط آن ها با این مفاهیم، چرایی استفاده از آن ها، موارد استفاده و ابزار های آن ها ارائه می شود. در نهایت جمع بندی از کل مطالب و دستاورد های این پژوهش ارائه می شود.۲- ادبیات موضوع۱-۲ بلاکچینبلاکچین یک شبکه نظیر به نظیر ذخیره اطلاعات است که مجموعه‌ای از تراکنش‌ها را به صورت امن و پیوسته، بدون نیاز به ایجاد امنیت توسط موجود ثالثی، به صورت غیر‌متمرکز ذخیره می کند. می‌توان به بلاکچین به صورت دفترچه‌ای از تراکنش‌های مالی نگاه کرد که پس از ثبت یک تراکنش در آن، امکان ایجاد تغییر و یا حذف آن وجود ندارد. در سال 2009، بیتکوین (Bitcoin) اولین شبکه بلاکچین برای استفاده گسترده معرفی شد که هم‌اکنون پیشتاز رمزارز‌هاست. امروزه از بلاکچین برای تبادل انرژی، حساب و کتاب مالی، رسانه و سرگرمی و خرید و فروش استفاده می شود.[1] در ادامه به‌صورت مختصر برخی مفاهیم مهم در بلاکچین را معرفی می‌کنیم.قراردادهای هوشمندقرارداد‌های هوشمند، کد‌ها و برنامه‌هایی بر بستر بلاکچین هستند که تنها در شرایطی که برای آن برنامه‌ریزی شده‌اند، قابل اجرا هستند. این قابلیت باعث می‌شود که کسب و کار‌ها به صورت خودکار و بدون نیاز به موجود ثالثی برای تایید شرایط، مدیریت شود. فرض کنید آلیس (Alice) قصد خرید مقداری طلا از باب (bob) دارد. در روال عادی، باب می‌تواند پول را دریافت کند ولی از واگذاری طلا امتناع کند. همچنین ممکن است آلیس طلا را بدون پرداخت مبلغ دریافت کند. حتی در صورت معامله، هر دو طرف امکان تکذیب دارند. اما این معامله می تواند به صورت امن، خودکار و بدون امکان تکذیب، به کمک قرارداد‌های هوشمند بر بستر بلاکچین صورت گیرد.نحوه ذخیره سازی داده‌هاهمانطور که مطرح شد، بلاکچین دفترچه از تراکنش هاست. این دفترچه دسته‌هایی از تراکنش‌ها به صورت پیوسته به هم متصل شده‌اند و هر دسته‌ی جدید از تراکنش تنها به انتهای دفترچه می‌تواند اضافه شود. تراکنش ها در دسته‌هایی به نام بلاک (block) ذخیره می‌شوند. اگرچه این مفهوم بین تمامی شبکه‌های بلاکچین مشترک است، اما فرمت ضبط و ثبت تراکنش‌ها بین آن‌ها می‌تواند متفاوت باشد. بطور کلی، بلاکچین‌ها در فرمت تراکنش‌های آن‌ها، به دو دسته مبتنی بر حساب (Account-based) و مبتنی بر خروجی (Utxo-based) تقسیم می شوند. در دسته اول، تراکنش ها به صورت انتقال ارز از یک حساب به حساب دیگر ذخیره می‌شود. این در حالی است که در دسته دوم، ارز ها در جعبه‌هایی هستند و یک تراکنش، تعدادی جعبه را در ورودی خرج می کند و تعدادی جعبه در خروجی می‌سازد و موجود هر حساب از ارز داخل جعبه‌های متعلق به آن حساب مشخص می شود.پروتکل ثبت تراکنش جدیدتراکنش‌ها برای ثبت در شبکه، باید مورد تایید مجموعه‌ی گره‌های شبکه قرار گیرند. این گره‌ها برای تایید، از پروتکل مشخصی استفاده می‌کنند و نحوه انتخاب و روند ثبت تراکنش جدید در بلاکچین تاثیر مستقیمی بر سرعت، امنیت و مقیاس پذیری آن‌ها دارد. تقریبا همه‌ی بلاکچین‌ها یکی از دو مفهوم اثبات کار(Proof of work) و اثبات سهام(Proof of stake) را بکار می‌برند. در اثبات کار، هرکس که بتواند یک مقدار مشخصی را به همراه لیستی از تراکنش‌ها ارائه کند، تراکنش‌های او ثبت می‌شود. این مقدار مشخص که nonce نامیده می‌شود، داده‌ای از بلاک است که با هدف ایجاد یک بلاک با مقدار هش با خصوصیت خاصی مقدار دهی می‌شود. برای مثال، مقدار هش بلاک پیشنهادی، باید با عبارت aabbccddeeff شروع شود. ایجاد چنین بلاکی، تنها با امتحان کردن مقادیر مختلف برای nonce امکان پذیر است و توان محاسباتی زیادی نیاز دارد. در طرف مقابل، در اثبات سهام، افراد، متناسب با مقدار سهامی که دارند، به نوبت می‌توانند تراکنش‌های جدید را انتخاب کنند. این سهام‌ها براساس میزان ارز و یا توکنی است که فرد در قرارداد هوشمندی قفل (لاک) کرده است. شبکه اتریوم، یک شبکه مبتنی بر اثبات کار بود که در چند ماه اخیر به اثبات سهام تغییر پیدا کرده است. از شبکه‌های مبتنی بر اثبات کار نیز می‌توان از ارگو نام برد.استیبل کوین‌ها (stable coins)استیبل کوین‌ها، ارز‌های دیجیتالی هستند که قیمت آن‌ها تقریبا ثابت است و ارزش آن‌ها توسط یک دارایی فیزیکی مانند واحد پولی یک کشور مثل دلار، یا طلا و غیره تعیین می‌شود. استیبل کوین‌ها برای تسهیل تبادلات مالی در سطح بلاک چین طراحی شده‌اند؛ به این معنی که مثلا برای پرداخت دلار به فرد دیگر از طریق بلاک چین، نیازی به خرید یک ارز دیجیتال به اندازه کافی متناسب با قیمت آن به دلار، خرید و انتقال آن به فرد مقابل به طریقی و سپس تبدیل ارز به دلار توسط فرد نیست و کافیست به مقدار لازم استیبل کوین به فرد واریز شود. از معروف ترین استیبل کوین‌ها می‌توان USDT [2] در شبکه TRON را نام برد که معادل یک دلار است. XAUt [3] نمونه‌ی دیگر از استیبل کوین‌هاست که معادل طلا است و به‌صورت توکن ERC-20 در شبکه اتریوم در دسترس است.۲-۲ معماری نرم‌افزارمعماری نرم‌افزار با ارائه‌ی مجموعه‌ای از اسناد به معماران سیستم و ذی‌نفعان کمک می‌کند تا دید‌های متفاوتی از ساختار نرم‌افزار به صورت کلان در کوتاه‌ترین زمان داشته باشند و سعی می‌کند محتوایی را ارائه دهد تا مهندسین نرم‌افزار با استفاده از آن‌ها از بسیاری از تصمیمات اشتباه در مسیر توسعه‌ی محصول فاصله بگیرند و در اصل عامل پیشبینی شرایط دشوار برای ساخت و توسعه‌ی نرم‌افزارها باشد.اما معماری نرم‌افزار در طرف دیگر مسیر توسعه، نقش واسط میان ذی‌نفعان و توسعه دهندگان نرم‌افزار را دارد؛ به شکلی که با استفاده از ابزار‌ و مدل‌های گوناگون در هر بخش از نرم‌افزار نحوه و معیار رسیدن به اهداف و نیازمندی‌های نهایی کسب و کار را در سطوح بالای توسعه محصول به نمایش می‌گذارد. در واقع معماران در این حوزه سعی دارند تا برخی از ویژگی‌های توصیفی و غیر قابل سنجش از نرم‌افزار نهایی را با استفاده از معیار‌هایی به صورت تحلیلی و قابل فهم برای تمامی ذی‌نفعان ارائه کنند.۱-۲-۲ انواع نیازمندی‌هانیازمندی‌های کارکردیاین دسته از نیازمندی‌ها، در اصل همان مجموعه اعمال مهمی هستند که یک کاربر باید آن‌ها را انجام دهد تا به هدف نهایی که دریافت خدمات دلخواه خود هست، برسد. هر دو گروه توسعه دهندگان و ذی‌نفعان محصول باید کاملاً به این نیازمندی‌ها مسلط باشند و محیا کردن بستری برای ارائه خدمات مربوط به این نیازمندی‌ها از اولویت‌های اول‌ آن‌ها باشد.نیازمندی‌های غیر کارکردیبه صورت کلی خصوصیات کلی یک سیستم را شرح می‌دهند و در اصل می‌توان گفت که محقق نشدن آن‌ها باعث نمی‌شود که سیستم برای ارائه خدمات اصلی خود دچار مشکل شود ولی هرچه محصول به تحقق آن‌ها نزدیک‌تر شود، در واقع کیفیت نرم‌افزار خود را ارتقاع داده است.در معماری نرم‌افزار، اگرچه تحقق نیازمندی‌های کارکردی در دستور کار قرار دارد، اما تمرکز اصلی در رسیدن به بهترین کیفیت قابل ارائه به ذی‌نفعان است.۲-۲-۲ معیارها و ویژگی‌های کیفیتی· کارایی:ارزیابی واکنش سیستم به برخی اتفاقات تأثیر گذار بر اجزای محیط نرم‌افزار که بیشتر به صورت اندازه‌گیری زمان پاسخ‌ها در یک بازه زمانی مشخص سنجش می‌شود.· قابلیت یکپارچگی:میزان تطبیق پذیر بودن سیستم مورد نظر برای برقراری ارتباط با دیگر نرم‌افزارهای خارجی که سنجش فاصله میان اجزای دو طرف در این بخش ارائه می‌شود.· قابلیت استفاده:یکی از مهم‌ترین ویژگی‌های کیفی، قابلیت استفاده است. این ویژگی مرتبط با استفاده‌ی کاربر از سیستم است و به بیان میزان رضایت کاربر از خدمات ارائه‌شده و سهولت استفاده از آن‌ها در فرایند می‌پردازد.· قابلیت اطمینان:معیاری برای ارزیابی میزان تحمل سیستم در یک شرایط از پیش تعیین شده، از جهت زیرساخت و یا خود لایه برنامه کاربردی· امنیت:معیاری برای ارزیابی میزان محافظت سیستم از داده‌ها در مقابل دسترسی عامل‌های غیر مجاز در عین ایجاد دسترسی مجاز برای افراد مشخص شده.· قابلیت نگه‌داری:مهارت و قابلیت سیستم برای پشتیبانی از ایجاد تغییرات در نرم‌افزار‌ها که ممکن است به نیازمندی‌های قدیمی و یا به طور کل یک نیازمندی جدید باشد.· تغییرپذیری:بیانی از میزان تغییرات ناشی از ایجاد یک تغییر در سیستم است و به میزان انتشار تغییرات به دیگر قسمت‌ها می‌پردازد.· آزمایش‌پذیری:بیانی از میزان تغییرات ناشی از ایجاد یک تغییر در سیستم است و به میزان انتشار تغییرات به دیگر قسمت‌ها می‌پردازد.· مقیاس‌پذیری:قابلیت سیستم برای تحمل افزایش فشار بار در نرم‌افزار بدون کاهش عملکرد در دیگر بخش‌ها را اندازه‌گیری و ارزیابی می‌کند.· قابلیت استفاده مجدد:احتمال استفاده از یک بخش یا کامپوننت از سیستم در دیگر قسمت‌ها با ایجاد کم‌ترین تغییرات ممکن را نمایش می‌دهد. بهینه کردن دانه‌بندی، کاهش نسخه‌برداری بی‌رویه از کد‌ها و جداسازی مسئولیت‌ها از دغدغه‌های اصلی این معیار کیفی است.· قابلیت پشتیبانی:قابلیت سیستم برای آماده کردن اطلاعات و ابزارها در جهت حل مشکلات پیش آمده برای نرم‌افزار است که از مخاطرات آن می‌توان به ضعف تحلیل عملکرد و فعالیت‌های سیستم، نبود ابزار جهت عیب‌یابی مانند ابزار تهیه snapshot و اصلاح خودکار بخش‌ها و نبود ابزار برای بررسی سلامت نرم‌افزار به صورت مقطعی در بازه‌ی زمانی مشخص اشاره کرد.· قابلیت فعال بودن:به کلیه زمانی که سیستم آماده به ارائه خدمات به کاربران است و می‌توانیم به دریافت خدمات از آن اطمینان کنیم، می‌پردازد. از معیارهای سنجش آن می‌توان به تعداد دفعات از کار افتادن سیستم و زمان بین آن‌ها، میزان زمان توسعه محصول تا استقرار آن در محیط استفاده و زمان لازم برای به‌روزرسانی اجزای نرم‌افزار اشاره کرد.۳- صحبت اصلی۱-۳ مفاهیم نرم‌افزار‌های مبتنی بر بلاکچینهر نرم‌افزار، متناسب با هدف طراحی آن و استفاده‌ای که از آن می‌شود، تمرکز بر مفاهیم خاصی دارد. در برخی نرم‌افزار‌ها، یکپارچگی و محرمانگی داده‌ها اهمیت دارد و در برخی دیگر، سرعت و کارایی اولویت بالاتری دارند. نرم‌افزار‌های مبتنی بر بلاکچین نیز مانند دیگر نرم‌افزار‌ها، مفاهیم مخصوص خود را دارند. در‌ادامه برخی از این مفاهیم را معرفی می‌کنیم و سپس الگو‌های پرتکرار در این نرم‌افزار‌ها را به همراه تاثیر آن‌ها به این مفاهیم و علت استفاده از آن‌ها مطرح می‌کنیم.قراردادهای هوشمندهمانطور که گفته شد، قرارداد‌های هوشمند، کد‌ها و برنامه‌های بر بستر بلاکچین هستند. به‌این‌ترتیب، طراحی آن‌ها از معماری و الگو‌هایی پیروی می‌کند. همچنین به‌علت محدودیت‌های شبکه بلاکچین، مباحثی چون حجم و سرعت اجرای این کد‌ها بسیار اهمیت دارد. درواقع انواع پیچیدگی در کدها می‌تواند به صورت مستقیم تاثیر زیادی در هزینه نهایی ایجاد کند و از طرفی در عملکرد و مقیاس پذیری بلاک‌ها اختلال ایجاد کند. وابسته به هدف نرم‌افزار مبتنی بر بلاک چین، بخشی از آن ممکن است قرارداد‌های هوشمند باشد و با توجه به مواردی که مطرح شد، طراحی قرارداد‌ها، یکی از مفاهیم مورد توجه در این نرم‌افزار هاست.مدیریت داده در بلاکچینقطعا هر نرم‌افزاری با مجموعه داده‌ای سروکار دارد. طبیعتا نرم‌افزار‌های مبتنی بر بلاکچین با داده‌های داخل شبکه در ارتباط هستند و در برخی از آن‌ها نیاز به ذخیره‌سازی داده‌ها در شبکه، برای استفاده از خصوصیت یکپارچگی و تغییر ناپذیری بلاکچین می‌باشد. ذخیره‌سازی داده به‌وسیله تراکنش ها امکان‌پذیر است و مشابه با قرارداده‌های هوشمند، حجم داده تاثیر مستقیم بر هزینه مورد نیاز برای تراکنش می‌گذارد. علاوه‌بر محدودیت حجم تراکنش در ذخیره داده، نرخ پردازش تراکنش‌ها در بلاکچین نیز تاثیر گذار است. با توجه به نیاز و وابستگی اکثر نرم‌افزار‌ها به داده، الگو‌های مدیریت آن‌ از اهمیت ویژه‌ای برخوردار است و تاثیر مستقیمی بر معیار‌های عملکرد، یکپارچگی و امنیت دارد.وارد کردن اطلاعات از خارج شبکهماهیت برخی از داده‌ها، اعم از حجم، امنیت، مبدا و نرخ تغییرات آن‌ها، از ذخیره‌سازی دائم آن در شبکه جلوگیری می‌کند. همچنین برخی از داده‌ها از چندین منبع به‌دست می‌آیند. برای استفاده از این داده‌ها، به پروتکلی برای وارد کردن این داده و اطلاعات به شبکه نیاز است. نرخ بروزرسانی، میزان اعتماد به منتشر کننده‌ی داده و همچنین مبدا داده‌ی ورودی، پارامتر‌های انتخاب روش مناسب برای وارد کردن داده‌ها به شبکه بلاکچین هستند. برای مثال، برای تبادل استیبل کوین‌ها با ارز شبکه، نیاز به ارزش ارز شبکه در واحد کوین است که دائما در حال تغییر است و راهکاری برای وارد کردن این مقدار در فاصله زمانی کوتاه به شبکه نیاز است. از ویژگی‌های کیفی متاثر، می‌توان به دسترس‌پذیری، امنیت و قابلیت یکپارچگی اشاره کرد.امنیت و حریم خصوصیاین پژوهش مرتبط با بلاکچین‌هایی هست که به‌صورت عمومی در دسترسی هستند. طبیعتا هر فرد می‌تواند به داده‌ها و تراکنش‌های ذخیره شده در شبکه دسترسی داشته‌باشد. در‌نتیجه، نرم‌افزار‌های مبتنی بر بلاکچین، در‌صورت نیاز به حریم خصوصی، باید خود آن را ایجاد کنند. در برخی موارد داده‌ها در بلاکچین ذخیره می‌شوند و نیاز به ایجاد شرایطی که تنها گروه خاصی قابلیت دسترسی به آن را داشته باشند وجود دارد. همچنین پرداخت به صورت ناشناس و پنهان سازی دارایی از موارد استفاده از حریم خصوصی است و بستری برای ایجاد آن نیاز است.امنیت داده‌ها و همچنین امنیت نرم‌افزار‌های مبتنی بر بلاکچین دیگر مفهوم مورد توجه است. متناسب با هدف نرم‌افزار و همچنین ویژگی‌های آن، مواردی هستند که در امنیت آن تاثیر گذارند. برای مثال، برخی نرم‌افزار‌ها نیاز به ایجاد تراکنش در شبکه از آدرس‌هایی غیر از قرارداد‌های هوشمند دارند که نیازمند کلید خصوصی یک آدرس برای خرج کردن دارایی‌های آن است. در‌صورت نشت پیدا کردن کلید خصوصی، فرد می‌تواند تراکنش دلخواه ایجاد کند و در روند نرم‌افزار اختلال ایجاد کند. همچنین دارایی‌های آدرس در خطر است و فرد می‌تواند به آدرس دلخواه خود منتقل کند. در‌نتیجه، حفظ کلید خصوصی به‌صورت امن از نیاز‌های امنیتی نرم‌افزار هست.باید توجه داشت که برخی الگو‌ها قصد ایجاد امنیت و حریم خصوصی در نرم‌افزار‌های مبتنی بر بلاکچین را دارند و در عین حال برخی الگو‌ها در نرم‌افزار‌هایی استفاده می‌شوند که قصد ایجاد امنیت و حریم خصوصی در سطح بلاکچین را دارند. در این پژوهش الگوهایی را بررسی می‌کنیم که در سطح بلاکچین این دو ویژگی را ایجاد می‌کنند. چرا‌که امنیت و حریم خصوصی در نرم‌افزار یه مفهوم کلی و مفصل است و مختص به هدف این پژوهش نمی‌شود. البته با معرفی الگو‌های مرتبط با ایجاد حریم خصوصی، بحث استفاده از خدمات آن نرم‌افزار‌ها را در دیگر نرم‌افزار‌های مبتنی بر بلاک چین را نیز مطرح می‌کنیم.نرم‌افزار‌های متمرکز و غیر متمرکزهمانطور که در فصل گذشته مطرح شد، بلاکچین یک شبکه غیر‌متمرکز است. اما نرم‌افزار‌های آن می‌توانند چنین نباشند. نرم‌افزار‌های مبتنی بر بلاکچین در هر دو صورت متمرکز و غیر‌متمرکز وجود دارند و انتخاب معماری مناسب براساس هدف نرم‌افزار، تاثیر مستقیمی بر ویژگی‌های کیفی یکپارچگی، اطمینان، امنیت، مقیاس پذیری، پشتیبانی و قابلیت فعال بودن و تاثیر غیر مستقیمی بر کارایی، آزمایش پذیری، قابلیت نگه‌داری و استفاده مجدد دارد. اگرچه ایجاد چنین معماری پیچیدگی‌های مخصوص خود را دارد، اما عموما بهتر است در نرم‌افزار‌هایی که امکان آن وجود دارد استفاده شود. چرا‌که تاثیر مثبت و قابل توجهی بر کارایی، اطمینان و مقیاس پذیری دارد.مهاجرت داده‌ها و پشتیبان‌گیریدیگر مفهوم مورد توجه در بلاک چین و نرم‌افزار‌های آن، بحث مهاجرت داده‌ها و پشتیبان‌گیری از آن‌هاست.پشتیبان‌گیری یکی از ارکان حفاظت از سیستم است و ایجاد شرایط مناسب برای آن، از مواردی هست که باید به آن توجه نمود. از طرف دیگر، بلاکچین‌ها و نرم‌افزار‌ها دستخوش تغییر می‌شوند و در برخی موارد، برای افزایش کارایی، کاهش هزینه و حتی ارائه خدمات بیشتر، نرم‌افزار‌ها از بلاک چینی به بلاکچین دیگر انتقال پیدا می‌کنند. متناسب با نرم‌افزار، داده‌های آن نیز ممکن است نیاز به مهاجرت داشته باشند و با‌توجه به خصوصیات بلاک چین، پیچیدگی‌هایی ایجاد می‌شود. برخی الگو‌ها برای سهولت مهاجرت بین شبکه‌ای و برخی در رابطه با پشتیبان‌گیری و نسخه‌برداری از داده‌های داخل شبکه ارائه می‌شوند.تبادلات مالی و خرید در بلاکچینیکی از ویژگی‌های اصلی بلاکچین فرآیند خرید در آن است که در ابتدا توجه بسیاری از سازمان‌ها را برای انجام تراکنش‌های مالی فرامرزی جلب کرد زیرا بدون نیاز به واسطه‌های بسیار مانند تراکنش‌های سنتی بانکی می‌تواند به راحتی و بدون محدودیت کاربران را به هدف خودشان برساند.اگر بخواهیم معماری کلی فرآیند خرید را در بستر بلاکچین تشریح کنیم می‌توانیم به ۳ عامل اصلی بپردازیم:صادر کننده توکنخریدار محصولفروشنده محصولشکل ۱ -فرآیند خریدبرای تبادل محصول و ارز بین این سه عامل، الگو‌ها و طراحی‌های مختلفی وجود دارد و متناسب هر‌یک، ویژگی‌های کیفی مختلفی متاثر می‌شوند. برای مثال، در یک طراحی صادر کننده (issuer) توکنی را بر اساس قوانینی که از قبل تنظیم کرده منتشر می‌کند. سپس تعدادی توکن در اختیار خریدار (buyer) قرار می‌دهد و خریدار با استفاده از آن توکن‌ها، اقدام به خرید محصولاتی که از قبل برای خرید با آن توکن خاص تعیین شده‌اند، اقدام می‌کند. فروشنده (seller) محصول را به خریدار تحویل می‌دهد و سپس توکن را دریافت می‌کند. توکن استفاده‌شده باید از بین برود تا دیگر فرصت استفاده از آن به خریدار داده نشود.۲-۳ الگوهای نرم‌افزاریبه‌طور کلی، الگوهای نرم‌افزاری برای جلوگیری و حل مشکلات و پیچیدگی‌هایی هستند که در زمان توسعه نرم‌افزار ایجاد می‌شوند و می‌توان آن‌ها را به سه دسته کلی تقسیم کرد:الگوهای معماریالگوهای برنامه کاربردیالگوهای سطح دانه‌بندی(سطح کد)هریک از الگو‌ها، مستقل از سطح هدف، برخی ویژگی‌های کیفی را تحت تاثیر قرار می‌دهند. این تاثیرات می‌توانند مخرب و همچنین مفید باشد و انتخاب یک الگو باید متناسب با نیاز‌ها و اولویت مفاهیم مورد استفاده در نرم‌افزار باشد. برای مثال، یکی از مفاهیم مورد بررسی در نرم‌افزار های مبتنی بر بلاکچین، نحوه ذخیره‌سازی داده‌ها برروی آن است. برای برخورد با این مسئله، سه الگو رمزنگاری داده‌ها بر بلاکچین، استفاده از توکن برای مالکیت و ذخیره هش داده بر بلاکچین معرفی شده‌است. طبیعتا تاثیر هریک بر ویژگی‌های کیفی و بخصوص کارایی متفاوت است. در این مسئله، انتخاب الگو متاثر از حجم داده، میزان اهمیت آن و دفعات نیاز به آن است.در ادامه الگو‌های پرتکرار را معرفی می‌کنیم و علت و فواید استفاده از آن‌ها را به همراه مواردی که در دو بلاکچین اتریوم و ارگو استفاده شده‌است ذکر می‌کنیم.۳-۳ الگوهای نرم‌افزاری مرتبط با بلاکچینالگوی Contract Registryقراردادهای هوشمند هم مانند دیگر ارکان نرم‌افزاری دچار تغییر و بروزرسانی می‌شوند اما در بلاک چین به دلیل ساختار غیر قابل تغییر، امکان تغییر یک قرارداد وجود ندارد و باید به صورت قرارداد جدید در آدرس جدیدی ایجاد شود. این عمل موجب اختلال در نرم‌افزار‌ها و دیگر بخش‌های وابسته به این قرارداد می‌شود؛ چراکه این بخش‌ها از آدرس جدید خبردار نمی‌شوند. همچنین در‌صورت اطلاع از تغییر، ایجاد بروزرسانی پیچیدگی‌های خود را داراست.برای حل این مشکل می‌توانیم از رویکرد DNS برای نحوه اتصال به قراردادها استفاده کنیم، به این صورت که با استفاده از یک مرکز به نام contract registry به هر قرارداد با آدرس مورد نظر، نام و مشخصات در سطح انتزاع دلخواه الحاق می‌کنیم و سپس هرگونه درخواست را با استفاده از این مرکز ارتباطی پوشش می‌دهیم. در واقع در این روش توانسته‌ایم قرارداد‌های جدید را مدیریت کنیم و دسترس‌پذیری آن‌ها را نیز بهبود دهیم.سرویس ENS در اتریوم یک نمونه است که ارتباط بین قرارداد هوشمند و منابع خارجی را به‌صورت اسم‌های ساده ایجاد می‌کند. در ارگو نیز، نرم‌افزار ErgoNames با این هدف ایجاد شده است و سرویس DNS تحت حمایت بلاکچین Ergo به صورت غیر متمرکز ایجاد کرده است.[4][5]الگوی Data Contract این الگو، جداسازی داده از منطق قرارداد هوشمند و ذخیره‌سازی آن در قرارداد جدا را مطرح می‌کند. مشابه با الگوی Contract Registry، قرارداد‌ها دستخوش تغییر می‌شوند و نسخه‌ی جدید لزوما قادر به دسترسی به داده‌های نسخه قدیمی نیست. از طرفی امکان استخراج داده‌ها از نسخه‌های قدیمی بسیار هزینه‌بر است و در برخی موارد مسائل امنیتی را به‌دنبال دارد. جداسازی داده از منطق قرارداد باعث می‌شود که دسترسی نسخه‌های جدید نیز به داده‌ها ثابت بماند و وابستگی و پیچیدگی میان داده و قرارداد کاهش یابد. از پروژه‌های در بستر اتریوم که از این الگو استفاده می‌کنند می‌توان colony را نام برد که از یک قرارداد هوشمند با ساختار داده عمومی برای ذخیره‌سازی داده‌های خود استفاده می‌کند.[6]الگوی Factory Contractیک الگو در طراحی قراردادهای هوشمند، ایجاد یک قرارداد هوشمند برای ساخت قرارداد‌های جدید از یک قالب مشخص است. برخی قرارداد‌ها در بلاکچین از قالب مشخصی پیروی می‌کنند و برای ایجاد مورد مشابه، ایجاد قرارداد جدید از روی آن قالب لازم است. از جمله این قرارداد‌ها، می‌توان به ERC-20 در اتریوم، BEP20 در بایننس (Binance) و EIP-04 در ارگو اشاره کرد که استاندارد دارایی و توکن‌ها را بیان می‌کنند.[7][8]ایجاد یک قرارداد و درخواست اضافه کردن آن به شبکه، یک عمل خارج از شبکه است و در این موارد تضمینی بر پیروی آن قرارداد از قالب مشخص وجود ندارد و در‌برخی موارد می‌تواند موجب مسائل امنیتی شود. این در شرایطی است که اگر قراردادی برای ساخت قرارداد هوشمند در سطح شبکه باشد، این مشکل حل می‌شود و نیاز به محاسبات خارج از شبکه نیز نیست. هرچند که در این الگو، محاسبات در سطح شبکه انجام می‌شود و هزینه را افزایش می‌دهد.الگوی Incentive Executionتوابع و قراردادهای هوشمند به‌‌خودی‌خود اجرا نمی‌شوند و یک تراکنش و یا قرارداد دیگر عامل اجرای آن‌هاست. عموما برای اجرا و ایجاد این تراکنش‌ها، سرویس‌هایی خارج از شبکه قرار داده‌ می‌شوند، اما اختلال در این سرویس‌ها، اختلال در روند اجرایی خواهد بود و می‌تواند کارایی را کاهش دهد. همچنین در برخی موارد، ارسال تراکنش و یا اجرای تابع به‌صورت ناشناس، نیازی برای ایجاد حریم خصوصی در سیستم است. در این الگو، جایزه‌ای برای کسی که تراکنش را بسازد قرار داده‌می‌شود. به‌ این‌ ترتیب هرکس می‌تواند سرویس خود را برای ایجاد این تراکنش‌ها قرار دهد و جایزه‌ی خود را هم دریافت کند. Alarm Clock، یک سرویس در اتریوم است که به کمک آن می‌توان یک تابع را برای اجرا در بلاکی خاص برنامه‌ریزی کرد و این سرویس برای اجرای آن توسط کاربران، جایزه‌ای در‌نظر گرفته است. در RosenBridge نیز، موجودیت Watcher و تراکنش ساخت EventTrigger به همین الگو دلالت دارند.[9][10]الگوی Encrypting On-chain Dataیکی از الگو‌های مرتبط با مدیریت داده‌ها در بلاک چین، رمزنگاری آن‌هاست. در این الگو، داده‌ها با الگوریتمی مشخص در خارج از شبکه رمزنگاری و داخل شبکه ذخیره می‌شوند. به‌این‌ترتیب، اگرچه که تراکنش‌ها به‌صورت عمومی در دسترسی هستند، اما داده‌های ذخیره شده در آن‌ها رمزنگاری شده‌است و تنها کسانی که کلید متناظر را داشته باشند می‌توانند به آن‌ها دسترسی پیدا کنند. با استفاده از این الگو، در عین استفاده از ویژگی‌های بلاکچین نظیر امنیت و تغییر ناپذیری، می‌توان حریم خصوصی و کنترل دسترسی به داده‌ها را ایجاد نمود. البته باید توجه داشت که امنیت داده‌ها وابسته به قدرت رمزنگاری آن‌هاست و استفاده از الگوریتم‌های ضعیف و روش‌های نادرست برای رمزنگاری داده‌ها، امنیت داده‌ها را تضمین نمی‌کند و موجب شکسته‌شدن و نشت پیدا‌کردن داده‌ها می‌شود.شکل ۲ - معماری الگوی Encrypting on-chain Dataبرخی مخاطرات این روش:کلید‌ها در لایه خارجی هستند پس هر لحظه در خطر نفوذ قرار دارند.به دلیل تغییر ناپذیری تراکنش‌ها هر کاربری که به کلید دست پیدا کند برای همیشه به تراکنش دسترسی دارد.محدود شدن امکانات قرارداد‌های هوشمندیکی از استفاده کنندگان این الگو اوراکلایز (Oraclize) است. اوراکلایز به صورت یک قرارداد هوشمند در بستر بلاکچین اتریوم به کاربران و توسعه دهندگان نرم‌افزار اجازه می‌دهد از بیرون زنجیره به داده‌های رمزگذاری شده دسترسی داشته باشند و فقط هسته مرکزی اوراکلایز هست که کلید خصوصی را در اختیار دارد. همچنین MLGBlockchain از دیگر پروژه‌های استفاده کننده از این الگو است که پیش از اشتراک گذاری داده‌ها در بلاکچین، آن‌ها را رمز می‌کند.[11][12]الگوی Tokenizationاز توکن‌ها می‌توان برای نشانه‌گذاری و نمایندگی یک دارایی فیزیکی و یا یک سرویس استفاده کرد. استفاده از توکن به نمایندگی از یک دارایی محدود به بلاکچین نمی‌شود و از قدیم مورد استفاده بوده‌است. توکن‌های کازینو یک نمونه بارز است که نماینده واحد پول است و در کازینو با واحد پول تبادل می‌شود. استیبل کوین‌ها که در فصل گذشته معرفی شدند، نمونه‌ی بارز استفاده از این الگو هستند. از استیبل کوین‌های معادل یک دلار می‌توان USDC در شبکه اتریوم و SigmaUSD در شبکه ارگو را نام برد.[13][14]این الگو، علاوه‌بر تسهیل تبادلات مالی، برای کنترل دسترسی نیز می‌تواند استفاده شود. برخی موارد، به‌خصوص زمانی که از الگوی Incentive Execution استفاده می‌شود، نیازی به داشتن کلید خاصی برای ایجاد تراکنش نیست. در این موارد، برای کنترل دسترسی و یا ایجاد شرایطی که تنها افراد مشخصی بتوانند تراکنش بزنند، می‌توان از توکن استفاده کرد. به‌این‌ترتیب تنها کسانی که دارای توکن خاصی باشند قادر به ایجاد آن تراکنش هستند و در سطح قرارداد هوشمند، دارا بودن آن توکن بررسی می‌شود. در پروژه RosenBridge، چند مورد دسترسی به کمک توکن ایجاد شده‌است. موجودیت Watcher با خرید توکن مشخصی، می‌تواند درخواست‌های انتقال را ضبط و گزارش کند. همچنین در بخش پاکسازی (cleanup service) این پروژه، تنها افراد مشخصی می‌توانند درخواستی را به عنوان تقلب نشانه‌گذاری کرده و اقدامات لازم را انجام دهند.[15][16][17]الگوی Blockchain Anchorبرای استفاده از خصوصیات بلاکچین نظیر تغییرناپذیری، لزوما احتیاجی به ذخیره داده‌ها در بلاکچین نیست. این الگو، ذخیره‌سازی هش (Hash) داده‌ها را به منظور تضمین صداقت آن‌ها مطرح می‌کند. در مواردی که حجم داده‌ها بسیار زیاد است، امکان ذخیره‌سازی خود آن‌ها و یا مقدار رمز شده به دلیل هزینه زیاد وجود ندارد. اما می‌توان هش داده‌ها را ذخیره کرد و در زمان تایید کردن، هش را محاسبه و با هش ذخیره شده در بلاکچین مقایسه نمود. این الگو در بخش‌های مختلف نرم‌افزار قابل استفاده است. در پروژه RosenBridge، هش بخشی از داده‌ها محاسبه و با نام کامیتمنت (Commitment) در بلاکچین ذخیره می‌شود (علت این کار در محدوده این پژوهش نیست) و در ادامه از این مقدار برای تایید داده‌های مطرح شده استفاده می‌شود. در اتریوم، قرارداد هوشمند Chainy، ابزاری برای این الگو است که لینک دسترسی به یک داده خارج از شبکه را به همراه هش آن در شبکه ذخیره می‌کند.[18][19]الگوی Oracle(Voting,Decentralised Oracle)اوراکل‌ها، درگاه‌های ارتباطی شبکه بلاکچین با خارج شبکه هستند. این نرم‌افزار‌ها، با نرخ مشخص، تراکنش‌هایی تولید می‌کنند که حاوی اطلاعات و داده‌های خارج از شبکه هستند. همانطور که در بخش قبل مطرح شد، برخی از داده‌ها به دلیل نرخ بروزرسانی و یا مبدا آن‌ها، باید به طریقی وارد شبکه بلاکچین شوند. برای مثال در شبکه ارگو، اوراکلی برای وارد کردن قیمت ارز ارگ به دلار وجود دارد که تقریبا هر 6 بلوک (معادل 12 دقیقه) قیمت جدید را وارد شبکه می‌کند. همچنین قیمت اتریوم به دلار به همراه مقدار ارائه شده توسط هر اوراکل در لینک زیر قابل مشاهده است.[20][21]اوراکل‌ها در هر دو دسته متمرکز و غیر‌متمرکز وجود دارند. اوراکل‌های متمرکز عموما در مواردی استفاده می‌شوند که مبدا داده‌ی ورودی یکتا باشد و نیازی به چندین منتشر کننده نباشد، هر‌چند که استفاده از یک اوراکل باعث ایجاد یک نقطه شکست (single-point-of-failure) می‌شود.شکل ۳ - معماری اوراکلدر‌جهت حذف نقطه شکست و همچنین ایجاد اعتماد بیشتر به داده‌ی ورودی، اوراکل‌های غیر‌متمرکز مطرح شدند که چندین گره در اوراکل، داده را وارد شبکه می‌کنند و به کمک مکانیزم‌های رأی‌گیری، داده به‌صورت یکتا تولید می‌شود. برای مثال، قیمت استیبل کوین‌ها، میانگین مقادیر ارائه‌شده توسط گره‌های اوراکل است و تایید ارسال و دریافت یک محموله، وابسته به تایید حداقل تعدادی از گره‌های اوراکل است.شکل ۴ - معماری اوراکل غیر متمرکزدر این میان، برخی از نرم‌افزار‌ها به ثبت وقایع بلاکچین در خارج از شبکه می‌پردازند که به آن‌ها اوراکل معکوس ReverseOracle گفته می‌شود. اوراکل‌های معکوس تقریبا جزئی از هر نرم‌افزار مبتنی بر بلاکچین هستند چرا‌که این نرم‌افزار‌ها به‌گونه‌ای درگاه ارتباطی بین بلاکچین و شبکه خارجی هستند، اما عموما منظور از این اوراکل‌ها، مواردی تنها با هدف ارتباط داده و عموما غیر‌متمرکز است. از آن‌ها می‌توان identitii را نام برد که درگاه ارتباطی تبادلات مالی و ارسال اسناد بین بلاکچین و پروتکل SWIFT است.[22]شکل ۵ - معماری اوراکل برعکسالگوی Multiple Authorizationاین الگو متناظر با الزام چند تایید است. برخی موارد، برای ارائه خدمات، انجام عمل مشخص و یا به ساده‌ترین روش ممکن، ارسال تراکنش، تایید چند فرد و موجودیت لازم است. این الگو برای حل این مسئله، مجموعه‌ای از n آدرس را تعریف می‌کند که تایید m عضو از آن برای تایید یک پرداخت لازم است. این الگو با نام Multi Signature هم شناخته می‌شود و بیانگر الزام تایید حداقل m نفر از n نفر برای ایجاد یک تراکنش است. اصولا به آدرس‌هایی که چنین تاییدی برای مصرف دارایی‌های آن‌ها لازم است، آدرس‌های مالتی‌سیگ گفته می‌شود و برخی از کیف‌پول‌ها قابلیت ایجاد آن‌ها را دارند.این آدرس‌ها به کمک مبحث رمزنگاری و در سطح قرارداد‌های هوشمند پیاده‌سازی می‌شوند و جزئیات آن خارج از محدوده‌ی این پژوهش است. Guarda یک کیف‌پول اتریوم با قابلیت ایجاد آدرس مالتی‌‌سیگ است. همچنین Gnosis نیز مفهومی مشابه با این آدرس‌ها را ارائه می‌کند. در ارگو، Minotaur تنها کیف‌پولی است که چنین آدرس‌هایی را پشتیبانی می‌کند. از موارد استفاده از این آدرس‌ها، می‌توان پروژه‌ی RosenBridge را نام برد که آدرس لاک(Lock) در ارگو، یک آدرس مالتی‌سیگ است و موجودیت گارد‌ها افرادی هستند که تایید آن‌ها برای ایجاد تراکنش لازم است.[23][24][25][26]الگوی دیگر برای حل این مشکل، Threshold Signature است که نباید این الگو اشتباه گرفته شود. Threshold Signature کاملا مشابه با مالتی‌سیگ، تایید m نفر از n نفر برای پرداخت لازم است، اما این موضوع به کمک مفاهیم رمزنگاری و بدون استفاده از قرارداد‌های هوشمند پیاده می‌شود و عملا یک آدرس است که برای پرداخت از آن، تجمیع m نفر لازم است. جزئیات و مفاهیم رمزنگاری این الگو از محدوده‌ی این پژوهش خارج است و برای مطالعه‌ی بیشتر، منابع [27][28][29] در دسترس هستند.الگوی Hot and Cold Wallet Storageدر الگو‌ی قبل، آدرس‌هایی معرفی شدند که تایید چند نفر برای پرداخت از آن‌ها لازم بود. در شرایطی که اطمینان و امنیت به‌دلیل تایید چند نفر افزایش می‌یابد، ریسک به خطر افتادن دارایی‌ها نیز به دلیل وجود چند کلید و احتمال از دست رفتن آن‌ها نیز افزایش می‌یابد. برای حل این مشکل، دو کیف‌پول و آدرس ساخته می‌شوند. آدرس گرم (Hot) فقط مقدار لازم از دارایی را دارد و آدرس سرد (Cold) در‌بر دارد. از آدرس گرم برای تبادلات و تراکنش‌ها استفاده می‌شود و تنها زمانی که دارایی آن از حد مورد نیاز کمتر می‌شود، دارایی از آدرس سرد به آن منتقل می‌شود. به‌این‌ترتیب، در صورت از دست رفتن کلید، تنها دارایی‌های آدرس گرم در خطر است. کلید‌های متناظر با آدرس سرد به‌دلیل استفاده محدود از آن، امن‌تر ذخیره می‌شود و احتمال از دست رفتن آن کم است. MyEtherWallet یک نمونه کیف‌پول گرم است. در پروژه RosenBridge، آدرسی که موجودیت گارد‌ها برای پرداخت درخواست‌ها استفاده می‌کنند، آدرس گرم است و به‌صورت دوره‌ای، دارایی‌ها از آدرس گرم به آدرس سرد منتقل می‌شود و از جمع شدن آن‌ها در آدرس گرم جلوگیری می‌کند.الگوی Master and Sub Key Generationکلید اصلی و فرعی، یک الگو برای سهولت مدیریت چندین آدرس در جهت افزایش حریم خصوصی است. در برخی موارد، برای ایجاد حریم خصوصی، تنها یکبار استفاده از آدرس مجاز است و در این شرایط، صد‌ها و شاید هزاران آدرس باید ساخته شود. مدیریت این آدرس‌ها بسیار پیچیده می‌شود و امکان خطا و نشت و نقض امنیت وجود دارد. برای حل این مشکل، یک کلید اصلی ساخته می‌شود و از آن، برای ساخت کلید‌های فرعی و آدرس‌های یکبار مصرف استفاده می‌شود. لزوما این الگو برای استفاده یکبار مصرف نیست و تقریبا تمامی کیف‌پول‌ها، یک کلید اصلی و یا نمونیک (mnemonic) معادل آن را در اختیار کاربر قرار می‌دهند و برای آدرس‌های مورد استفاده، کلید‌های فرعی از کلید اصلی تولید می‌کنند. در ارگو، به‌غیر از کیف‌پول‌ها، پروژه میکسر (mixer) نیز از کلید اصلی و فرعی برای تولید آدرس‌های میکس استفاده می‌کند.[30]الگوی Time-Constrained Accessبرخی از دسترسی‌ها در دنیای ما به مدت زمان خاصی محدود می‌شوند. این موضوع در بلاکچین هم وجود دارد و در برخی موارد نیاز به پیاده‌سازی چنین دسترسی لازم است. برای مثال، زمانی که درخواستی برای مبادله صورت می‌گیرد، اگر یکی از طرفین مبادله از ادامه‌ی آن سرباز زند، طرف دیگر باید بتواند دارایی خود را برگرداند. در این مسئله، بازه‌ی زمانی برای مبادله باید تعیین گردد و طرفین اقدام مورد نیاز را در آن بازه انجام دهند.پیاده‌سازی این دسترسی به کمک قرارداد هوشمند قابل انجام است و برای بیان زمان، از بلاک‌های شبکه استفاده می‌شود. طبیعتا زمان متناظر با تعداد بلاک برای هر بلاکچین متفاوت است. در اتریوم، تقریبا هر 12 ثانیه بلاک جدید تولید می‌شود و این زمان در ارگو تقریبا هر 2 دقیقه است. برای مثال، فرض کنید شبکه ارگو در بلاک 10000 است. برای محدود کردن خرج کردن یک دارایی برای یک ساعت آینده، کافیست شرطی گذاشته شود که اگر بلاک حال حاضر از 10030 کمتر بود، امکان پرداخت وجود دارد. این شرط به کمک قرارداد هوشمند گذاشته می‌شود. عموما در موارد تعویض و تبادل دارایی، شرطی برای لغو تبادل بعد از مدت زمان مشخص قرار داده‌می‌شود که مثالی برای این الگو است.الگوی X-Confirmationپایه‌ای ترین الگو مرتبط با امنیت در بلاکچین، صبر برای تاییدیه یک بلاک و یا تراکنش به تعداد کافی است. اگرچه بلاکچین تغییرناپذیر است، اما در‌حقیقت بلاکچین‌هایی که از اجتماع ناکاموتو (Nakamoto Consensus) استفاده می‌کنند، تغییر‌ناپذیری را ارائه می‌کنند که با احتمال تعیین می‌شود. بلاک‌های بلاکچین، از اجتماع تایید گره‌های متفاوت بدست می‌آید. اگر 2 مجموعه گره همزمان بلاک جدید و متفاوتی را اضافه کنند، تنها یکی از آن‌ها معتبر است. تعیین انتخاب بلاک معتبر با اجتماع ناکاموتو انجام می‌گیرد و بلاکی که طولانی‌تر باشد معتبر است. در‌نتیجه، تراکنش‌هایی که در بلاک غیر معتبر هستند، در شبکه وجود نخواهند داشت و به اصطلاح فورک (Fork) می‌شوند.با‌توجه به توضیحات بالا، برای اطمینان از تایید یک تراکنش و بلاک، بهتر است تا ثبت شدن چند بلاک بعد از آن منتظر ماند. با ثبت هر بلاک، احتمال فورک شدن بلاک‌های قبل به شدت کاهش می‌یابد، چراکه برای فورک کردن، هزینه محاسباتی بسیار زیادی لازم است. به تعداد بلاک ثبت شده بعد از یک بلاک، تعداد کانفیرمیشن (Confirmation) گفته می‌شود. در اتریوم، 10 کانفیرمیشن برای تایید یک بلاک پیشنهاد می‌شود.این الگو یکی از پایه‌ای ترین الگو‌ها در ارتباط با بلاکچین است و تقریبا در هر نرم‌افزاری که با تایید و یا ارسال تراکنش سروکار دارد استفاده می‌شود. در کیف‌پول‌ها، بعد از ارسال تراکنش، تعداد کانفیرمیشن آن قابل مشاهده است و اکسچنج‌ها (Exchanges)، تعداد تایید مورد نیاز و تعداد کانفیرمیشن حال حاضر برای تایید سپرده نمایش می‌دهند.الگوی Token Burningبه محض اینکه توکن استفاده می‌شود یعنی در زمانی که خریدار از توکن برای رسیدن به هدف خود استفاده نهایی را می‌کند همانطور که اشاره شد صادر کننده باید آن توکن را از بین ببرد و یا بلااستفاده کند. همین شرایط برای یک دید داده محور به بلاکچین هم قابل تشریح است مثلاً کلیه حالات یا قرارداد‌های هوشمندی که دیگر قابل استفاده نیستند باید به نحوی پردازش شوند که دیگر نشود از آن‌ها در بستر برنامه استفاده کرد.برای اجرای سناریو گفته شده در بالا ۳ روش پر تکرار پیشنهاد می‌شود که بنا بر شرایط می‌توانیم از هر کدام استفاده کنیم:فروشنده محصول توکن را به یک آدرس غیر فعال ارسال می‌کند(این آدرس کلید خصوصی متناظر با آن را ندارد) و در این صورت توکن مورد نظر غیر قابل استفاده مجدد می‌شود.ایجاد یک تابع برای از بین بردن توکن‌ها در قرارداد هوشمند که در صورت صدا زدن توکن مورد نظر آن را از بین می‌برد.ایجاد قرارداد‌های هوشمندی که خود مخرب باشند؛ به شکلی که اگر توکنی دریافت کردند، خود به خود از بین بروند. این روش به‌دلیل محاسبات تحت شبکه، عموما هزینه بر است.در حالت کلی با اجرای این روش‌ها یکپارچگی و امنیت نرم‌افزار افزایش می‌یابد اما از طرفی دیگر ممکن است این فرآیند‌ها هزینه‌های زیادی را برای محصول ایجاد کنند و قابلیت ردیابی هم بسیار کاهش می‌یابد؛ زیرا در پایان با از بین رفتن توکن‌ها، دیگر دریافت داده و اطلاعات از آن‌ها لزوما ممکن نیست.دلایل مختلفی برای از بین بردن توکن‌ها می‌تواند وجود داشته باشد. یکی دیگر از آن دلایل، مهاجرت از یک بلاکچین به بلاکچین دیگر است. در این موارد توکن‌های تولید شده در بلاکچین مبدا باید از بین بروند. پروژه بایننس در زمان مهاجرت پایه اصلی پروژه خود از بیتکوین به اتریوم، درخواست از بین بردن توکن‌های موجود را از کاربران داشت.[31] در اتریوم، به‌صورت پیشفرض روشی برای از بین بردن توکن‌ها وجود ندارد و برای اینکار، توکن به آدرسی واریز می‌شود که توکن می‌تواند به آن وارد شود، ولی از آن خارج نمی‌شود. در ارگو این قابلیت وجود دارد و می‌توان توکن‌ها را در یک تراکنش از بین برد. البته امکان از بین بردن توکن اصلی شبکه، یعنی ارگ، وجود ندارد و برای چنین کاری باید مشابه با اتریوم، به آدرسی غیر قابل برداشت ارسال شود.الگوی Escrowدو طرف خریدار و فروشنده باید در انجام فرآیند خرید محصول طوری عمل کنند که تا زمان تحویل نهایی محصول بر اساس سند توافق شده برای سرویس کاربران تراکنش تمام شود و توکن‌ها به صورت کامل منتقل شوند. در غیر این صورت باید تدابیر مشخصی انجام شود که در ادامه فرآیند آن‌ها توضیح داده‌می‌شود.در مرحله اول، آن دسته از قوانین و شرایطی که توسط طرفین تعیین شده است، به صورت کامل ارائه می‌شود. سپس خریدار با در نظر گرفتن شرایط ذکر شده، اقدام به خرید و انتقال توکن‌ها به قرارداد هوشمند حاوی Escrow می‌کند. زمانی که Escrow از اتمام فرآیند‌ها بر اساس شرایط معین شده مطلع می‌شود، درستی آن‌ها را بررسی می‌کند. سپس در صورت صحت شرایط پیش آمده و تطبیق آن‌ها با قوانین، محصول را تحویل خریدار و توکن‌ها را به فروشنده می‌رساند. اما در صورتی که قوانین رعایت نشده باشد، عملیات را لغو کرده و توکن‌ها را به خریدار بر می‌گرداند.شکل ۶ - مدل ترتیبی الگوی Escrowبرای اجرای این روش باید توجه کنیم که تمامی اطلاعات مربوط به تحویل کالا به خریدار و توکن به فروشنده به صورت شفاف و بدون ابهام به آن‌ها ارائه شود. مثلاً اگر ۱۲ روز کاری برای تحویل کالا نیاز است، باید خریدار از ساعت و تاریخ شروع و پایان آن مطلع شود. از طرفی اگر قرارداد هوشمند برای تکمیل مراحل تطبیق قوانین، به داده‌های دیگر سرویس‌های خارجی نیاز داشته باشد، می‌تواند با استفاده از الگوهایی که بر مبنای اوراکل هستند عمل کند. Kleros، یک پروتکل حل اختلاف نظر آنلاین است که با این الگو مشکل را در بستر بلاکچین حل می‌کند.[32]الگوی Stealth Addressآدرس پنهان، آدرسی است که دارایی‌های آن می‌تواند متعلق به افراد مختلفی باشد و در عین حال، مشخص نیست که چه کسی آن دارایی را دارد. آدرس‌های معمولی، هر‌یک متناظر با یک زوج کلید عمومی و خصوصی هستند که دارنده‌ی آن، مالک دارایی‌های آن است. اما در آدرس پنهان، مالک یکتا وجود ندارد و متناسب با پارامتر‌‌های آن، هر فرد مالک بخشی از آن است و این مالکیت به کمک قرارداد‌های هوشمند و علوم رمزنگاری پیاده‌سازی می‌شود.این الگو کاملا متناسب با حریم خصوصی است و در صورتی که شخص نخواهد میزان دارایی او مشخص باشد، می‌تواند از این آدرس‌ها استفاده کند. باید دقت شود که این آدرس‌ها به‌صورت استخر‌های دارایی هستند و هرچه افراد بیشتری از آن‌ها استفاده کنند، حریم خصوصی آن‌ها بیشتر می‌شود. نحوه ایجاد این آدرس در ارگو به چند روش در فروم توضیح داده شده‌است [33] و همچنین پیاده‌سازی و اضافه کردن آن به پروژه میکسر در‌حال انجام است .[34]۴- دستاورد‌ها و جمع‌بندیدر مجموع همانطور که در بخش مقدمه نیز اشاره شد، در این پژوهش سعی شده تا نرم‌افزارهای مبتنی بر بلاکچین را به شکلی معمارانه مورد بررسی قرار دهیم. ابتدا در فصل ادبیات موضوع با اشاره به نکات اصلی موضوع تحقیق، تا سطح قابل قبولی در فضای مسئله وارد شدیم .سپس با استفاده از همان مبانی، الگوهای متداول در دنیای بلاکچین را از نگاه بهبود ویژگی‌های کیفی (Quality Attribute) مورد بررسی قرار دادیم و فناوری‌هایی که از آن‌ها استفاده کرده‌اند را به‌همراه ابزار‌هایی برای اجرای الگو‌ها معرفی کردیم.از دستاوردهای کلی این پژوهش می‌توان به موارد زیر اشاره کرد:مباحث حول محور معماری نرم‌افزار و بلاکچین به صورتی بیان شده‌است که خروجی این پژوهش به شکلی خلاصه و قابل فهم برای همه افراد علاقه‌مند به این موضوعات ارائه شود.سعی شده تا برای هر بخش، با ترکیب مبانی ذکر شده در دیگر منابع تحقیقاتی و تجربیات نویسندگان، اطلاعاتی از هر‌دو بخش پژوهشی و صنعتی جمع‌آوری شود.بخش‌های ویژه‌ای برای معماری نرم‌افزار‌های مبتنی بر بلاکچین معرفی شد.الگوهای معمارانه همراه با مصداق هر کدام در محیط صنعتی برای دو بلاکچین ارگو و اتریوم ارائه شده‌است.همچنین برای درک بهتر برخی الگو‌ها، از پروژه RosenBridge استفاده شده است که یک پروژه متن باز است و توضیحات و سند‌های آن به‌صورت عمومی در دسترس است. معرفی این پروژه مرتبط با این پژوهش نیست اما آشنایی با آن برای درک مثال‌های این پژوهش لازم است، ویدئو‌ی [35] هدف پروژه را به‌همراه روند آن بیان کرده است. ۵- نکات و پی‌نوشت--این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.--امیدواریم این مطلب برای شما مفید بوده باشه.۶- مراجع[1] https://aws.amazon.com/what-is/blockchain[2] https://tether.to/en[3] https://gold.tether.to[4] https://ens.domains[5] https://github.com/ergonames[6] https://colony.io/[7] https://ethereum.org/en/developers/docs/standards/tokens/erc-20[8] https://github.com/ergoplatform/eips/blob/master/eip-0004.md[9] https://www.ethereum-alarm-clock.com/[10] https://github.com/rosen-bridge/contract#3--event-trigger-creation[11] https://docs.provable.xyz/#ethereum-advanced-topics-encrypted-queries[12] https://mlgblockchain.com/crypto-signature.html[13] https://www.circle.com/en/usdc[14] https://sigmausd.io[15] https://github.com/rosen-bridge[16] https://github.com/rosen-bridge/contract#1--get-watcher-permit[17] https://github.com/rosen-bridge/contract#3--rsn-slash[18] https://github.com/rosen-bridge/contract#2--event-commitment-creation[19] https://chainy.info[20] https://explorer.ergoplatform.com/en/oracle-pool-state/ergusd[21] https://data.chain.link/ethereum/mainnet/crypto-usd/eth-usd[22] https://identitii.com/[23] https://guarda.com/multisignature-wallet/[24] https://gnosis-safe.io/[25] https://github.com/minotaur-ergo/minotaur-wallet[26]https://github.com/rosen-bridge/contract#contracts[27] https://link.springer.com/referenceworkentry/10.1007/0-387-23483-7_429[28] https://academy.binance.com/en/articles/threshold-signatures-explained[29] https://github.com/bnb-chain/tss-lib[30] https://github.com/ergoMixer/ergoMixBack[31] https://community.binance.org/topic/44/binance-chain-mainnet-swap[32] https://kleros.io/en/[33] https://www.ergoforum.org/t/stealth-address-contract/255#:~:text=A%20stealth%20address%20preserves%20recipient,%2Dtime%20address%20from%20it[34] https://github.com/aragogi/Stealth-doc[35] https://www.youtube.com/watch?v=Xsiy-yPJQ6w[36] Nicolas Six, Nicolas Herbaut, Camille Salinesi, Blockchain software patterns for the design of decentralized applications: A systematic literature review, Blockchain: Research and Applications, Volume 3, Issue 2, 2022, 100061, ISSN 2096-7209, https://doi.org/10.1016/j.bcra.2022.100061.[37] https://research.csiro.au Sina Farahani Sina Farahani Sun, 29 Jan 2023 23:34:46 +0330 https://virgool.io/@sinadsina78/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88-%D9%81%D8%B1%D8%A7%D9%86%D8%AA-%D8%A7%D9%86%D8%AF-okolrchhe71q ۱ - روند تکاملی فرانت-اندبرای تحلیل چرایی استفاده از میکروفرانت-اند و موارد کاربری آن باید ابتدا مسیر پیشرفت و نیازمندی‌های حوزه فرانت-اند را بررسی کنیم. در ابتدا پیدایش تکنولوژی‌های مبتنی بر وب کاربران را به استفاده از وب‌سایت‌ها هدایت کرد، در آن زمان بیشتر درگاه‌های آنلاین ارائه دهنده خدمات به صورت بسیار ساده و بدون ایجاد راه‌های تعاملی مشغول به انجام وظایف خود بودند. رفته رفته با افزایش استفاده از این نوع فناوری‌ها، نیازمندی‌های مورد انتظار هم تغییر پیدا کرد به صورتی که سطح تعامل بین کاربر و وب‌سایت افزایش یافت و همین مورد نیازمند ایجاد بستر‌هایی پیچیده‌تر برای ارائه خدمات بود. در نتیجه بازه زمانی ایجاد نسخه دوم وب(WEB 2.0) شامل تکامل سکوهایی شد تا بتوانند در دو لایه بک-اند و فرانت-اند با استفاده از صفحات وب خدمات گسترده‌تر و تعامل‌پذیرتری‌ را به کاربران خود ارائه کنند.در همین زمان استفاده از دستگاه‌های الکترونیکی جدیدی با صفحات نمایش کوچک‌تری در بازار رواج یافت و از طرفی با استقبال زیاد کاربران مواجه شد. از این رو بستر‌های ارائه دهنده خدمات از طریق درگاه‌های وب باید طوری روش‌های استفاده و دسترسی‌پذیری برنامه‌های کاربردی خود را تنظیم می‌کرند تا بتوانند در تمامی دستگاه‌ها و تمامی ابعاد خدمات خود را به خوبی به کاربران ارائه دهند.۲-۱ برنامه‌های کاربردی مخصوص سیستم عامل‌ها(Native Applications)حال با استفاده گسترده از تبلت‌ها و موبایل‌ها، برنامه‌های کاربردی مخصوص برای اجرا در بستر سیستم‌ عامل‌های این دستگاه‌ها توسعه یافت. از ویژگی‌های مهم این برنامه‌ها می‌توان به سرعت و عملکرد خوب، دسترسی‌پذیری و قابلیت استفاده بالا و طراحی بهینه اشاره کرد. رفته رفته کاربران از درگاه‌های وب هم انتظار داشتند تا مانند برنامه‌های کاربردی مخصوص سیستم‌ عامل‌ها عمل کنند.بنابراین با تغییر نیازمندی‌ها دوباره باید فناوری‌های جدیدتری به کار گرفته می‌شد تا کاربران به بهترین شکل ممکن از خدمات استفاده کنند. برخی از این نیازمندی‌ها:· ارائه پیام‌های مناسب به هر کاربر متناسب به وضعیت درخواست آن کاربر از برنامه.· طراحی و پیاده‌سازی برخی المان‌های حرکتی مانند زمان‌های بارگیری یا بارگذاری فایل.· برخی از اعمال بدون بارگیری دوباره صفحه(Refresh) باید انجام شوند.· در زمان بارگیری صفحه آن قسمت‌هایی که بارگیری نشده‌اند باید با طرحی متفاوت نمایش داده شوند.۲ - پیدایش میکرو فرانت-انداکنون نیازمندی‌های کاربران دائماً در حال تغییر است و آن‌ها انتظار دارند تا برنامه‌های مبتنی بر وب بتوانند در لایه رابط کاربری این نیازمندی‌‌ها را به ساده‌ترین شکل به آن‌ها ارائه کنند. از طرفی حوزه فرانت‌-اند هم در حال ارائه کتابخانه‌ها و فریمورک‌های جدیدتری به محیط توسعه لایه واسط کاربری است. تمامی موارد ذکر شده باعث انتقال مسئولیت و پیچیدگی زیادی به بخش فرانت‌-اند برنامه‌های مبتنی بر وب شده.در طرف دیگر ماجرا (Server Side) اما معماری میکروسرویس برای راحت‌تر کردن کار بخش توسعه و استقرار برنامه‌های کاربردی در حال استفاده در اکثریت سازمان‌ها بود. در صورتی که در لایه‌های پایینی نرم‌افزارها همه نیازمندی‌های ممکن را برای ایجاد چابکی در توسعه محصول و راحت کردن فرآیند‌های استقرار و ارائه نرم‌افزار را در محیط کسب و کار داشتند اما این لایه فرانت-اند بود که همچنان از نبود یک دیدگاه و به طور کلی معماری هماهنگ با این مبانی رنج می‌برد.حال توسعه‌دهندگان این حوزه باید معماری ارائه می‌کردند که اول در راستای مبانی میکروسرویس‌ها باشد و دوم نیاز‌های لایه فرانت-اند را نیز در نظر می‌گرفت. بنابراین ایده اولیه معماری و دیدگاه میکروفرانت-اند شکل گرفت به صورتی که نرم‌افزار به صورت عمودی به بخش‌هایی تقسیم می‌شود و هر بخش افراد و روش عملکردی مستقل خود را دارد سپس هر کدام از این افراد در تیم‌های خود مشغول به ارائه خدمات با استفاده از پایگاه‌داده مستقل گروه خود می‌شوند.۱-۲ ساختار کلی معماریتیم‌ها:هر گروه با یک اسم مرتبط به عملیات خود سعی دارد تا یک فعالیت مشخص که در نهایت ارزش و خدمت مورد نظر را برای کاربر هدف ایجاد می‌کند را به سازمان خود ارائه دهد. در اصل تفاوت اصلی این رویکرد در بخش ساختار افراد در روش تقسیم‌بندی آن‌ها است به صورتی که دیگر مانند قبل معیار گروه‌بندی فناوری‌ و تکنولوژی‌ها نیست بلکه در میکرو فرانت-اند معیار اصلی حوزه رفع نیازمندی‌های مختلف کاربران نهایی است. به عنوان مثال: تیم پیشنهاد دهنده، تیم محصول، تیم نقد و بررسی و...صفحه‌ها:همانطور که گفته شد تیم‌‌ها به صورت مستقل وظایف مشخصی را دنبال می‌کنند و آن‌ها را ارائه می‌دهند. این وظایف می‌توانند در قالب صفحات، بخشی از یک نیاز عملکردی و یا چندین بخش از یک صفحه باشد. تشخیص این موضوع که یک فرآورده یک تیم در کدام دسته از موارد ذکر شده قرار گیرد با نقطه‌های اشتراکی میان تیم‌ها است. در واقع ممکن است در یک صفحه برای فروش کالا نیاز به بخش پیشنهاد کالا و نقد و بررسی به صورت جداگانه در یک صفحه باشد و یا در صورت تشخیص به هر کدام صفحه‌ای جدا تعلق بگیرد.ادغام بخش‌ها(Integration):برای انجام دادن این بخش نیاز به اتصال قسمت‌‌های مختلف در ۳ مورد را داریم:1. اتصال در سطح صفحات:اگر بارگیری صفحه اهمیت زیادی نداشته باشد با استفاده از لینک‌ها می‌توان صفحات را به راحتی به یکدیگر متصل کرد اما در صورت عدم بارگیری مجدد صفحه‌ها باید از برخی فریمورک‌ها استفاده کرد.2. ترکیب‌بندی:در واقع هر صفحه مسئولیتی در قبال قرار دادن هر بخش در جای مخصوص به خود را ندارد و این یکپارچگی باید طی فرآیند دیگری انجام شود که به ۲ صورت است: ۱- ترکیب‌بندی سمت سرور۲- ترکیب‌بندی سمت کاربر3. ارتباط بخش‌ها:در پایان هم، هر بخش باید در داخل صفحات بتواند با بخش‌های دیگر در ارتباط باشد و واکنش مناسب را ارائه کند.موضوعات اشتراکی(shared topics):تا این قسمت حتما می‌دانیم که میکرو فرانت-اندبا تقسیم قسمت‌های مختلف برنامه به بخش‌های کوچک‌تر و کم ارتباط(‌loosely coupled) سعی در انتقال مفاهیم میکروسرویس به فرانت-اند را داشته‌است اما این ارتباط کم و کارکرد مستقل بخش‌ها باید در بعضی نقاط توسط معیارهایی کنترل و راهنمایی شود.کارایی وب:در میکرو فرانت-اند هر گروه به صورت مستقل برای رسیدن به هدف نهایی مورد نظر خود تلاش می‌کند و به دلیل گسترش این گروه‌ها و در نتیجه تولید کد‌های زیاد ممکن است برخی ناهماهنگی‌ها و افزونگی کد انجام شود. بنابراین باید همواره بر عملکرد و کارایی فرآورده‌های هر بخش نظارت وجود داشته باشد.سیستم طراحی:برای رعایت تداوم‌پذیری در بخش‌های متفاوت باید یک سیستم کلی و میان تیمی ارائه شود تا تمامی تیم‌ها بر اساس آن کامپوننت‌های خود را توسعه دهند. در این صورت با وجود اینکه هر بخش به صورت مستقل و جداگانه در حال توسعه است اما برای کاربر نهایی به شکل یک وب‌سایت واحد به نمایش در خواهد آمد.دانش اشتراکی:در بعضی موقعیت‌ها نیاز است تا تیم‌ها نکات مهم و تکرارپذیر خود را برای دیگر گروه‌ها به اشتراک بگذارند تا از دوباره کاری‌ها جلوگیری شود.۳ – میکرو فرانت-اند چه مشکلاتی را حل می‌کند؟تا اینجای این نوشته متوجه شدیم که معماری میکروفرانت-اند با تقسیم افراد در گروه‌هایی با ساختار عمودی سیستم سعی در پیشبرد فرآیند توسعه بخش‌های لایه فرانت‌اند را با سرعت و کارایی بهتر دارد که در این ساختار برای جلوگیری از بروز برخی مشکلات باید به نکاتی نظیر استفاده از معیارهای میان تیمی و به کار گیری تکنیک‌های ادغام بخش‌ها رو بیاوریم. حال که مبانی کلی و پایه‌ای میکروفرانت-اند را درک کردیم میخواهیم بدانیم که قرار است چه مشکلاتی را در طی پیاده‌سازی این معماری حل کنیم.۱-۳ توسعه محصول سریع‌ترفرض کنید که قرار است یک نیازمندی جدید در محصول پوشش داده شود، در معماری معمولی طی جلساتی میان افراد مختلف در تیم‌های متفاوت مبانی این امکانات جدید ارائه می‌شود تا به مرحله پیاده‌سازی کامل برسد. اما در میکروفرانت-اند می‌توانیم تمام افرادی که برای انجام آن نیازمندی جدید همکاری دارند را در یک گروه واحد قرار دهیم و کل مسیر پیاده‌سازی آن را برای یک محیط ثابت پیش ببریم. این موضوع خود باعث افزایش سرعت امکانات جدید در محصول می‌شود.۲-۳ حذف فرانت‌اند یکپارچهدیگر خبری از استفاده از کدهای فرانت‌اند به صورت یکجا نیست و در میکروفرانت-اند با تقسیم هر بخش برای توسعه هر قسمت از محصول بسیار راحت‌تر هستیم. برخی از فواید این معماری:· فرآیند استقرار مستقل· جداسازی و انزوای امکان بروز خطا و شکست در کد به یک بخش· راحتی در فهم و توسعه کد· افزایش امکان استفاده مجدد و بازیابی کد· پیشبینی‌پذیر تر بودن بخش‌ها زیرا دیگر حالت‌های(states) اشتراکی زیادی نداریم.۳-۳ قابلیت ایجاد تغییرات بنیادینهمانطور که در بخش اول گفته شد با تغییر روزمره نیازمندی‌های کاربران چه در محصول و چه در انطباق با فناوری‌های جدید محیط کسب و کار، این لایه فرانت‌اند است که بیشتر از اکثر بخش‌ها در طول زمان کم‌تری ممکن از تغییر کند. در این راستا توسعه دهندگان باید قادر باشند تا در شرایط مختلف تغییرات بنیادی را در ساختار هر بخش ایجاد کنند. مانند: تغییر در فریمورک‌ها رای انجام بعضی اعمال خاص در صفحه‌ها.از طرفی سازمان‌ها زمانی که تصمیم به ارائه محصول در بازارهای بزرگ می‌گیرند انتظار دارند تا بتوانند به سرعت در راستای رفع نیازمندی‌های محیط کسب و کار خود در هر دامنه مشخص اقدامات مورد نظرشان را اعمال کنند بنابراین باید علاوه بر به کار گیری از میکروسرویس در سطح‌های پایین‌تر از فرانت‌اند خود بخش فرانت محصول هم همیشه در نظر داشته باشیم.۴-۳ تصمیم‌گیری مستقلاینکه بتوانیم در هر بخش آزادانه امکان تصمیم‌گیری برای تغییر در تکنولوژی‌‌های مورد استفاده در آن بخش را داشته باشیم.(بدون توجه به درگیر شدن در فرآیند انجام انتقال هر سیستم به وضعیتی که نیازمندی‌های پذیرش آن فناوری جدید را داشته باشد.)قطعاً در معماری یکپارچه برای تغییرهای هر چند کوچک به دلیل وابستگی زیاد بین بخش‌ها باید قسمت زیادی از کدها را تغییر دهیم و چه بسا امکان این تغییر اصلاً فراهم نشود و مجبور به بازیابی تمامی کد پروژه شویم.اما در میکروفرانت-اند این آزادی را داریم که هر زمان با توجه به استقلال معماری میکرو(داخلی) تکنولوژی را تغییر دهیم و البته نیم نگاهی هم به مستندات و قوانین معماری ماکرو(خارجی) جهت اعمال تغییرات داشته باشیم.۴ – نکات منفی میکروفرانت-اندتمامی نقاط قوت و کارایی بالای این معماری بررسی و اشاره شد اما قطعاً مانند تمامی تصمیماتی که یک معمار نرم‌افزار باید بگیرد(همیشه نکات منفی و مثبتی وجود دارد) هیچگاه قطعیتی نسبت به موضوعی وجود ندارد و معمار باید نسبت به شرایط اقدامات لازم را ارائه کند. از این رو در این قسمت برخی نکات منفی معماری میکروفرانت‌اند نوشته شده است.۱-۴ افزونگیچندین تیم به صورت هم زمان در حال توسعه نرم‌افزار هستند و در اصل هر گروه قصد دارند تا استک تکنولوژی خود را توسعه دهند، هر تیم فرآیند استقرار و یکپارچه‌سازی مداوم مخصوص به خود را دارد و امکان دارد تا اسکریپت‌های JS/CSS داخل برنامه نهایی قرار داده شود که در تمام محصول بی‌جهت تکرار می‌شوند. به عنوان مثال: یک مشکل امنیتی در یک کتابخانه محبوب را در یک مکان مرکزی نمی‌توان رفع کرد بلکه تمامی بخش‌ها باید جداگانه به آن بپردازند.دلیل اصلی ایجاد همچین معماری که هیچ موردی را در بخش‌های خود با یکدیگر به اشتراک نمی‌گذارد این است که با تمامی موارد بالا باز هم نمی‌توان ضرر ایجاد وابستگی بالا را قبول کرد و این موارد را دچار نشد.۲-۴ تداوم و ثباتدر تمامی بخش‌ها هر تیم پایگاه‌داده جداگانه خود را دارد تا بتواند به صورت موازی و مستقل با آن کار کند اما در برخی موارد و برای بعضی بخش‌ها نیازمند استفاده از داده‌های ثبت شده در دیگر قسمت‌ها هستیم. در این موارد می‌توانیم از تکنیک‌های تکثیر داده‌ها مانند Even Bus و feed system استفاده کنیم. به عنوان مثال یک تیم غیر از خود تیم محصول به داده‌های این قسمت نیاز دارد، آن‌ها می‌توانند داده‌های محصول را تکثیر کنند تا اگر بخش محصول دچار مشکل شد این اختلال در کار آن‌ها تأثیر نگزارد. البته همچنان با استفاده از این تکنیک‌ها هم ممکن است سرعت پاسخ‌گویی به درخواست‌ها کاهش یابد و سیستم دچار اختلالات دیگری شود.۳-۴ ناهمگونیاستفاده از تکنولوژی‌های مختلف در هر گروه اگر بیش از اندازه شود خود باعث بروز مشکل در روند توسعه نرم‌افزار می‌شود. که باعث سخت شدن جابه‌جایی افراد در تیم‌های مختلف و استخدام افراد جدید می‌شود.۵ - چه زمانی میکروفرانت-اند استفاده شود؟۱-۵ برای پروژه‌های متوسط و بزرگیکی از اهداف اصلی میکروفرانت‌اند در اصل افزایش مقیاس‌پذیری سیستمی که از آن استفاده می‌کند است. بنابراین اگر نرم‌افزار با تعداد مشخص و کمی افراد در حال ارائه خدمان و توسعه است پس نیازی به استفاده از این معماری نیست زیرا استفاده از آن در سیستم‌های کوچک بسیار زیان‌آورتر است تا اینکه بتواند به سازمان کمکی کند. مثلاً اگر تعداد افرادی که در حال توسعه محصول هستند از ۱۰ نفر بیشتر شد و مدیریت و کنترل فرآیند‌ها سخت‌تر از قبل شد نیاز داریم تا تفکر میکروفرانت‌اند را اعمال کنیم.۲-۵ بهترین عملکرد برای وب‌سایت‌هاهر چند این معماری قابل استفاده برای تمامی بستر‌های ارائه دهنده خدمات که از لایه رابط کاربری بهره می‌برند هست اما باید توجه داشت که به عنوان مثال برای برنامه‌های مخصوص یک دستگاه(native APP) چون تمامی بسته‌های توسعه به صورت یک بسته واحد اجرا می‌شوند بنابراین استفاده از این معماری توجیه خاصی جهت بهینه کردن فرآیند توسعه نرم‌افزار ندارد.۳-۵ بهره‌وری در مقابل سرباردر ابتدای کار اول باید یکسری محدوده‌ها و قوانینی تعیین شود تا تمامی افراد از آن‌ها پیروی کنند و تیم‌ها در کد و خروجی کار هماهنگ و یکدست‌تر کار کنند. مثلاً استفاده از یک فناوری خاص در فریمورک ری‌اکت. همچنین ارائه یک راه ارتباطی جهت اشتراک‌گذاری دانش بین افراد هر تیم می‌تواند به بالا رفتن سطح عملکرد کلی سیستم کمک کند.با گسترش نرم‌افزار و استفاده از تیم‌های مختلف برای توسعه محصول بعضی پیچیدگی‌های جدیدی ایجاد می‌شوند و مدیریت تمام تیم‌ها خود می‌تواند بسیار زمان‌گیر باشد. مثلاً اگر در فرآیندی که چندین گروه در توسعه آن شرکت دارند مشکل به وجود آید مسئولیت رفع‌ آن به عهده کدام گروه است؟ یا محیط مرورگر‌های یک محیط اشتراکی است و همیشه در صورت بروز مشکل پیدا کردن منشع آن آسان نخواهد بود.۶ – در چه مواقعی استفاده از میکروفرانت‌-اند توصیه نمی‌شودهمانطور که گفته شد باید بزرگی پروژه‌ مورد نظر به حد قابل قبولی برسد تا بتوانیم آن را مناسب برای اجرای میکروفرانت-اند بدانیم. از طرفی نرم‌افزاری که قرار است ایم معماری برای آن پیاده‌سازی شود باید طوری تحلیل و طراحی شده باشد که برای تقسیم‌بندی آن به صورت عمودی در تیم‌های مختلف به مشکل بر نخوریم. در واقع نباید وظایف و موضوعاتی که گروه‌های قرار است حول آن‌ها کار کنند تداخل و یا هم‌پوشانی زیادی داشته باشند. زیرا در این صورت بحث‌ها و موارد غیر قطعی بسیاری رخ می‌دهد و این خود باعث از بین رفتن زمان مفید توسعه محصول می‌شود.اگر نیازمندی‌های محصول توسعه آن را در تعداد زیادی از پلتفرم‌ها الزامی بداند نیز استفاده از میکروفرانت توصیه نمی‌شود زیرا به علت افزایش تعداد پلتفرم‌ها یک تیم قادر به توسعه هر کدام از آن‌ها نمی‌باشد. به عنوان مثال نرم‌افزاری مانند Netflix که در تمامی دستگاه‌ها مانند تلویزیون‌ها، Setup Box، کنسول‌های بازی و گوشی‌های همراه و تبلت‌ها برنامه کاربردی فعال دارد و سعی می‌کند تا کدبیس خود در بستر وب و ارائه خدمات مختلف با استفاده از آن را در تمامی دستگاه‌های ذکر شده حفظ کند. توسعه چنین محصولی بر اساس معماری میکروفرانت-اند کمی با مشکل روبه رو می‌شود.۷ – سازمان‌های که از میکروفرانت-اند استفاده می‌کنندبا اینکه این دیدگاه در سال‌های اخیر موفق به ارائه کارایی خود شده‌است اما خیلی از شرکت‌ها از در سال‌ها قبل از آن استفاده می‌کردند.مانند آمازون که گفته می‌شود برای یکپارچه کردن بخش‌های مختلف در صفحات از تکنیک‌ها ادغام کد‌های فرانت استفاده می‌کند.البته در حوزه فروشگاه‌های الکترونیکی میکروفرانت‌-اند بسیار پر کاربرد بوده است. به عنوان مثال:OTTO Group، IKEA، Thalia از دسته فروشگاه‌های اینترنتی هستند که از این معماری استفاده می‌کنند. دیگر شرکت‌هایی که از مبانی این دیدگاه استفاده می‌کنند می‌توان به Spotify اشاره کرد. آن‌ها با استفاده از تیم‌هایی که اسم‌ آن‌ها را اسکوآد(squad) تعیین کرده‌اند در قالب فریمورک SAP اقدام به تقسیم افراد و فعالیت‌های سازمان در گروه‌هایی با استقلال بالا کرده‌است. Sina Farahani Sina Farahani Fri, 30 Dec 2022 18:48:21 +0330 https://virgool.io/@sinadsina78/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D8%A8%D8%B1%D8%AE%DB%8C-%D8%A7%D8%B2-%D9%81%D9%86%D8%A7%D9%88%D8%B1%DB%8C-%D9%87%D8%A7%DB%8C-%D8%AA%D8%A3%D8%AB%DB%8C%D8%B1-%DA%AF%D8%B0%D8%A7%D8%B1-%D8%A8%D8%B1-%D8%AF%D9%86%DB%8C%D8%A7%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-bxbvvpjuumyq طراحی مبتنی بر دامنه(Domain Driven Design)DDD به صورت جامع یک روش معمارانه است تا فضا و قوانین کسب و کار به لایه برنامه کاربردی نزدیک‌تر و از برخی دوباره کاری‌هایی که در نتیجه عدم توجه به تغییرات برخی نیازمندی‌ها رخ می‌دهد هم جلوگیری شود. حال برای ایجاد ارتباط میان بخش‌ها از مفاهیمی مانند مقادیر مرزی، دامنه، مدل و زبان مشترک استفاده می‌شود تا بتوان در طول توسعه محصول یکپارچگی تیم‌های مختلف حفظ شود و از طرفی مسیر انتخابی برای ساخت و نگه‌داری محصول با آنچه از دید فضای کسب و کار باید باشد فاصله نگیرد.نکات مثبتدر واقع با استفاده از این روش به صورت‌ها مختلف ارتباط میان افراد مختلف از بخش‌ها متفاوت را بسیار آسان کرده‌ایم و دیگر نیاز صرف زمان و منابع برای فهم مفاهیم پایه‌ای نداریم چون هر شخص با اصطلاحات و مسائل متداول که متخصصان دامنه تشخیص داده‌اند در دایره لغات زبان مشترک قرار گیرد، آشنا هستند.از طرفی از آنجایی که دیدگاه این روش بر مبنای شئ‌گرایی توسعه داده شده است بنابراین با استفاده از مفاهیمی از آن جنس مانند پیمانه‌بندی و محصورسازی می‌توانیم انعطاف پذیری المان‌هایی که برای آن‌ها در حال برنامه ریزی هستیم را افزایش دهیم.Hexagonal Architectureاین معماری در اصل با هدف ارائه یک رویکردی برای بیان نحوه برقراری ارتباط لایه‌ها در روش DDD ارائه شده است به صورتی که اگر فرض کنیم امکان دارد ارتباط میان لایه‌های چهارگانه(لایه دامنه، لایه رابط کاربری، لایه برنامه کاربردی، لایه زیرساخت) به درستی فهمیده نشود و محصورسازی آن‌ها تا حدودی نقض شود، حال برای اصلاح نگرشی که موجب این چنین اشتباهات می‌شود می‌توانیم از معماری شش‌ضلعی استفاده کنیم.بنابراین این معماری به صورتی بیان کننده معماری و پیاده‌سازی نرم‌افزارها بر مبنای روش دامنه محور است به صورتی که مطابق شکل زیر اگر شش ضلعی مرکزی را دامنه و منطق کسب و کار برنامه در نظر بگیریم که توسط لایه برنامه کاربردی احاطه شده است، این بخش توسط پورت‌ها که در اصل همان رابط کاربری معماری هستند وظیفه انتقال داده‌های مورد نیاز هر لایه را به لایه بعدی دارند.(بدون وابستگی به نوع و یا کاربری داده) از طرفی آداپتورها با اتصال به پورت‌ها با تکنولوژی‌هایی که در سمت دیگری از لایه برنامه کاربردی وجود دارند ارتباط برقرار می‌کنند.(مثلا با استفاده از Rest API)شکل 1 - معماری شش‌ ضلعی در حالت کلی از سمت چپ به راست با درخواست‌ها کاربر و یا سیستم‌های دیگر به برنامه لایه دامنه و برنامه کاربردی که در این معماری هسته مرکزی را تشکیل می‌دهد طوری بر اساس قوانین کسب و کار برنامه ریزی و توسعه داده می‌شود که بتواند درخواست‌های دریافت شده را از لایه زیرساخت دریافت کند و هدف اصلی بدست آید و علاوه بر آن با استفاده از این معماری می‌توانیم مشاهده کنیم که به اصل وارونگی وابستگی(SOLID) هم توجه ویژه‌ای شده است به صورتی که لایه‌هایی که قابلیت تغییر پایینی دارند و بالاتر هستند وابستگی کمتری به دیگر لایه‌ها دارند و البته توسط یک رابط کاربری پشتیبانی می‌شوند.Command and Query Responsibility Segregationهدف این روش در اصل ارائه یک رویکرد عملیاتی جهت بهتر کردن خواندن و نوشتن در پایگاه‌های داده است. به صورتی که فرض می‌کنیم با استفاده از روش‌های قدیمی و سنتی عملیات مدیریت پایگاه‌داده درحال پردازش عملیات یک نرم‌افزار هستیم اما با افزایش نیازمندی‌ها و پیچیده و بزرگ شدن فرآیند‌های پیاده‌سازی شده عملاً ادامه کار با استفاده از این روش‌ها سخت و غیر ممکن می‌شود در این زمان استفاده از روش CQRS که در واقع فرآیند درخواست خوانش و نوشتن در پایگاه‌داده را از یکدیگر جدا می‌کند می‌تواند موجب افزایش استقلال این دو بخش، بهینگی نمایش داده‌ها، امنیت و سادگی بیشتر درخواست‌هایی که سمت پایگاه داده می‌رود، شود.حال برای پیاده‌سازی این روش نیاز به ایجاد انزوا در دو سطح یعنی نرم‌افزار و سطح فیزیکی پایگاه‌داده داریم:سطح نرم‌افزار:در این سطح به عنوان مثال این تغییرات نیاز است: دستورات از حالت داده محور به فرآیند محور تغییر کنند.از طرفی سعی شود تا حد امکان دستورات به صورت همزمان اجرا شوند و درخواست‌هایی که به طرف پایگاه‌داده می‌روند صرفاً با یک شئ حاوی داده بازگردانده شوند(پایگاه‌داده تغییر نکند)سطح فیزیکی:اگر حتی قصد اعمال انزوای بیشتری بین خواندن و نوشتن باشیم می‌توانیم سطح جداسازی را فیزیکی‌تر کنیم به صورتی که مثلاً فرمان خواندن از پایگاه‌داده نمایش بصری مخصوص به خود را داشته باشد. در این صورت باید توجه داشته باشیم که نیاز به ایجاد ارتباط میان دستورات نوشتن و درخواست‌های خواندن الزامی است، بنابراین برای ایجاد این ارتباط می‌توانیم از Event Sourcingاستفاده کنیم.الگوی MVVMاین الگو را از لحاظ ساختار و نحوه عملکرد می‌توانیم به عنوان یکی از زیرمجموعه‌های MVC در نظر بگیریم اما زمانی که بیشتر به روش کارکردی آن توجه می‌کنیم، می‌توانیم تفاوت‌های بزرگی را دریابیم. ساختار MVVM شامل سه بخش اصلی است: مدل، دید، ویومدلشکل 2 - ساختار MVVM نحوه جریان فرآیندها و داده در این الگو به صورت تعاملی بین این 3 بخش تقسیم شده است. در view که صرفاً وجه نمایشی نرم‌افزار است اطلاعاتی که به وسیله View Model از model ارائه می‌شود را به کاربران نشان می‌دهد. این جداسازی view از model باعث می‌شود تا گروه‌های توسعه نرم‌افزار بتوانند راحت‌تر به صورت همزمان در هر دو بخش بدون نیاز به ایجاد تغییر در بخش دیگر به توسعه نرم‌افزار بپردازند و از طرفی viewو view model می‌تواند نقش یک رابط کاربری و واصل را برای model ایفا کند تا تغییراتی که در سطح کسب و کار به وجود می‌آید تأثیر حداقلی را روی model بگذارد.دو نوع ارتباط میان view و model برای انتقال داده برقرار است. که در یک نوع تغییرات model تنها به صورت یک طرفه در view نمایش داده می‌شود و در نوع دیگر این ارتباط به صورت دو طرفه و با اعمال تغییر متقابل اتفاق می‌افتد. حال نقش view model در این الگو در اصل بیشتر به صورت واسط میان دو بخش نمایش دهنده و حاوی داده‌ها است یعنی اگر حجم زیادی داده از model دریافت می‌کند، آن را طوری پردازش می‌کند تا قابل استفاده برای view هم باشد و عکس این فرآیند هم برقرار است. اما در بعضی نرم‌افزارها که سرعت پاسخگویی و راحتی کاربر در مشاهده تغییرات اهمیت دارد می‌توان این ارتباط را به صورت مستقیم بین view و model با استفاده از روش Data Binding برقرار کرد که البته در همه شرایطی توصیه نمی‌شود چون می‌تواند باعث استفاده بخش زیادی از منابع و اختلال در سرویس‌های بزرگ سازمان شود.Event Sourcingدر حالت کلی می‌دانیم که نرم‌افزارها سعی در ذخیره حالت لحظه‌ای(جاری) برنامه‌ را دارند که با همان تکنولوژی همیشگی CRUD انجام می‌شود اما استفاده متداوم از این روش برای ذخیره همه حالت‌های المان‌های برنامه می‌تواند موجب بروز تعارض در دستورهایی که همزمان اعمال می‌شوند و رفته رفته کاهش سرعت عملکرد برنامه شود. حال با در نظر گرفتن مشکلات ذکر شده می‌توانیم با استفاده از Event Sourcing در ابتدا نه تنها با دانستن حالت کنونی عملیات بلکه با ذخیره ترتیبی حالات گذشته یک سری از رویدادهایی که برای شئ مورد نظر اتفاق افتاده را هم در نظر بگیریم و بتوانیم در مواقع بحران و یا خرابی از آن‌ها استفاده کنیم.کلیت فرآیند روش به این صورت است که رابط کاربری دستوراتی که توسط کاربر در حال صادر شدن است را به مدل دامنه ارسال می‌کند در این لایه با استفاده از دسترسی‌های مختلف ارزیابی این دستورات انجام می‌شود سپس در صورت درستی در صحت سنجی دستورات بخش مورد نظر می‌تواند event ها را در پایگاه داده مخصوص به خودشان ثبت کند. در این صورت اگر کاربری نرم‌افزار به صورتی است که نیاز دارد تا هر چند وقت یکبار به عقب بازگردد یا دستوراتی را به طور کامل تغییر دهد و همیشه گذشته شئ مورد نظر برای سازمان اهمیت دارد، می‌تواند از پایگاه داده رویدادها استفاده کند.برخی از موارد کاربری روش به این صورت است:· برای بروز نگه‌داشتن خواندن و نوشتن در CQRS· زمانی که اعمالی مانند بروزرسانی و ثبت برخی ورودی‌ها را می‌توانیم از بقیه عملیات جدا کنیم تا به عنوان مثال عملکرد یک بخش بهتر شود.· زمانی که باید ریسک بروز تعارض در به‌روز رسانی‌ها را به حداقل برسانیم.Micro Frontendsبرای ارائه توضیحی شفاف‌تر از میکرو فرانت‌اند باید به کمی عقب‌تر برگردیم زمانی که توسعه نرم‌افزارهای مبتنی بر وب به صورت یکپارچه انجام می‌شد. به این صورت که تیم‌های برنامه‌نویسی به صورت مشترک روی یک پروژه کار می‌کردند اما رفته رفته با تغییر ساختار و معماری توسعه بک‌اند و شکل گیری تفکر سرویس‌گرایی در نرم‌افزارها برنامه نویسان فرانت‌‌اند متوجه از هم گسیختگی این قسمت نسبت به بخش‌های دیگر برنامه شدند و از طرفی با پیشرفت تکنولوژی مورد استفاده کاربران نیازمندی‌های جدیدی بروز پیدا کرد که فناوری‌های قدیمی فرانت قادر به پشتیبانی از آن‌ها نبودند.حال با توجه به ارائه فریمورک‌های جدید و به دنبال آن معماری‌های متفاوت این امکان ایجاد شد تا بخش‌های فرانت هم با دریافت ساختار و چارچوب بتوانند با معماری میکروسرویس هماهنگ شوند. بنابراین در این مقطع دیدگاه میکرو فرانت‌اند به وجود آمد. این دیدگاه با الهام از دید کلی میکروسرویس قصد دارد تا برای هر بخش از نرم‌افزار که به سطح مورد نظر رسیده است تیم‌های جدا برای توسعه در نظر بگیرد، به صورتی که بتوان به طور همزمان و بدون بروز تعارض توسعه بخش فرانت انجام شود.برخی مزایا:· قابلیت توسعه مستقل هر بخش· آزادی در انتخاب تکنولوژی‌های مختلف برای توسعه· تشکیل تیم‌های خود مختارLow code platformsعموماً نرم‌افزارها یا بسترهایی که برای استفاده از آن‌ها نیازی به زمینه فنی و مهندسی وجود نداشته باشد و کاربر سطح اول به صورت پیش‌فرض لازم نباشد که دانش بالایی از روش‌های ساخت نرم‌افزار و برنامه‌نویسی آن‌ها داشته باشد. در حالت کلی این گونه از محصولات باید دارای رابط کاربری گرافیکی و ساده برای عموم کاربران باشد تا هر فردی در سطوح و بخش‌های مختلف سازمان بتواند با کمترین دانشی در مورد آن تکنولوژی محصول خود را با استفاده از این بستر گسترش دهد و به هدف سازمانی خود برسد.از مزایای این نوع نرم‌افزارها می‌توان به نکات زیر اشاره کرد:· افزایش سرعت توسعه و انتشار نرم‌افزار· راحت‌تر کردن فضای حل مسئله برای افرادی که آشنایی زیادی با محیط فناوری اطلاعات ندارند· راحت کردن کار تیم‌های برنامه نویسی با ایجاد بستری برای رفع بعضی نیازها که موجب می‌شود تا برنامه‌نویسان برای موضوعات چالشی‌تر وقت صرف کنند.اما از طرفی رفته رفته با گسترش سازمان مدیران ارشد توانایی کنترل و بررسی نوع داده‌های خروجی از این نوع برنامه‌ها را از دست می‌دهند و حتی اصلاً بحث نگه‌داری و توسعه برخی از این نرم‌افزارها خود باعث ایجاد چالش می‌شود. بنابراین باید دانست چه زمانی مناسب است برای استفاده از این نوع نرم‌افزارها و چه زمانی دیگر باید استفاده از آن‌ها را متوقف کنیم.Enterprise Service BusESB در اصل یک بستر نرم‌افزاری است که وظیفه دارد تا جریان انتقال داده میان کامپوننت‌ و سرویس‌های مختلف را مدیریت کند، به شکلی که در هر دو صورت یکپارچه و توزیع شده مانند یک کلید سوییچ وظیفه تعیین مسیر ارتباطی داده‌ها را مطابق با سیاست‌های کلی فناوری اطلاعات سازمان‌ها بر عهده دارد. بر خلاف میکروسرویس در ESB بخش‌های مختلف به مرکزیت این تکنولوژی بدون وابستگی به فناوری خاصی تنها راه‌های انتقال داده‌ها را مشخص می‌کند.زمانی که از این فناوری استفاده می‌کنیم در اصل تغییرات در کامپوننت‌ها و یا افزودن آن‌ها را بسیار آسان کرده‌ایم و از طرفی به بخش امنیتی سیستم هم می‌توانیم کمک کنیم زیرا ESB فرآیند مانیتورینگ و گرفتن لاگ را آسان می‌کند. همچنین با استفاده از load balancing عملکرد نرم‌افزار را بهبود می‌بخشد.برخی اصول ESB:· تنظیم و هماهنگ کننده ارتباطی· برقرار کننده این ارتباط برای هر بخش بااستفاده از تکنولوژی انتقال داده همان برنامه(Json,SOAP)· همچنین استفاده از پروتکل‌های انتقال متفاوت برای بخش‌های مختلف· ایجاد رابط‌های کاربری متفاوت برای استفاده در مواقع عقبگرد و یا مسیرهای جایگزیندر چند سال اخیر فضای کسب و کارهای مختلف به سمت ایجاد چابکی حداکثری رفته است در نتیجه برای لایه زیرساخت نیز این نیاز به شدت حس می‌شود که جهت کاهش هزینه و راحتی در تغییرات می‌توان از برخی فناوری‌ها مانند ESB بهره برد.API GetawayAPI Getaway در اصل نقش واسط میان API های مختلف یک سیستم و بخش مدیریت کننده درخواست‌ها را دارد به صورتی که اگر سرویسی در حال صدا زدن API خاصی باشد API Gataway درخواست یا درخواست‌های دریافت شده را میان سرویس‌های مرتبط پخش می‌کند تا تمامی بخش‌های متأثر در جریان این درخواست باشند و از طرفی در صورت نیاز بعضی سرویس‌های عملکردی در قسمت بک‌اند هم فراخوانی می‌کند. در واقع وظیفه اصلی در اینجا این است که با وجود تمامی پیچیدگی‌های نرم‌افزار و نحوه ارتباطی در میان سرویس‌های مختلف API Gataway سعی می‌کند تا با آسان‌ترین مسیر ممکن با مدیریت درخواست‌های روابط کاربری مختلف تمامی نیازمندی‌های کاربر را آماده کند.حال می‌توانیم نتیجه بگیریم که سازمان‌ها از این فناوری استفاده می‌کنند چون:· باید طی مکانیزمی جلوی استفاده بیش از حد از API ها را گرفت.· بعضی کسب و کارها نیاز به تحلیل نحوه استفاده کاربران از API ها را دارند.· اگر API های سازمان تجاری سازی شده باشند، برای مدیریت پرداخت‌ها به API Gataway نیاز داریم.· در صورت استفاده از معماری میکروسرویس که یک درخواست ممکن نیازمند صدا زدن صدها برنامه دیگر شود.· یک مدل یکپارچه از تمامی API ها ارائه شده در محصول شما و قابل مشاهده برای کاربراندر حالت کلی با افزایش استفاده از فناوری‌هایی مانندDevOps, Microservice و serverless Cloudموارد کاربری API Gataway نیز افزایش می‌یابد زیرا همه‌ی این فناوری‌ها از API ها برای انجام فرآیندهای خود استفاده می‌کنند در نتیجه بهره بردن از یک معماری که باعث یکپارچه‌سازی و مدیریت درخواست‌ها از رابط کاربری به سمت سرویس‌ها می‌شود می‌تواند موجب بدست آوردن ارزش‌های زیادی برای سازمان‌ها بشود.نرم‌افزار مدیریت فرآیندهای کسب و کارBPMSبه سازمان‌ها کمک می‌کند تا بتوانند بسیاری از عملیات و فعالیت‌ها را که عموماً وقتی انجام می‌شوند منجر به رسیدن سازمان به هدف تعیین شده خود می‌شود را دسته‌بندی کرده و به صورت خودکار پردازش کند. اکثر این فعالیت‌ها در مجموع ساختاری پیچیده دارند و بعضاً تکرار شونده و می‌توانند تابع الگو خاصی باشند که با بررسی و بهینه کردن مسیر انجام آن‌ها می‌توان از هدر رفت مقدار زیادی از منابع سازمانی جلوگیری کرد.مراحلی که طی آن‌ها فرآیندهای سازمان بررسی و بهینه می‌شوند به این صورت است:1. طراحی: فرآیند را بشکن و در هر قطعه مسیرهای جدیدی را طراحی کن(یا باز طراحی)2. مدل: فرآیندها را به صورت بصری ارائه کن تا برخی جزئیات را بتوانیم مدیریت و تغییر بدهیم.3. اجرا: فرآیند بدست آمده را آزمون کن.4. بررسی لحظه‌ای: به صورت لحظه‌ای مسیر انجام کارها را زیر نظر بگیر تا از درستی انجام کار و اثر گذاری آن مطمعن شوی.5. بهینه کردن: در مجموع در طول همه مراحل بالا اگر احساس کردی که تغییری نیاز است انجام شود تا سیستم بهتر عمل کند الان وقتش هست.مزایا و معایب BPMS:افزایش سرعت ارائه محصول به بازار، بهبودی هزینه‌ها، بهره‌وری و کیفیت، افزایش رضایت کاربران، ساده کردن فرآیندهای پیچیده، مدیریت ریسک، راحتی در ارائه فرآیندهای جدید و در پایان افزایش برگشت‌پذیری سرمایه‌های ارائه شده برای انجام آن فرآِیند. اما باید توجه داشت که به علت ارائه مجموعه‌ای از نرم‌افزارها در قالب نرم‌افزار مدیریت فرآیندهای کسب و کار نباید انتظار پرداخت هزینه کمی جهت استفاده از خدمات این نوع برنامه‌ها داشت و در اصل می‌توان گفت یکی از معایب این دست خدمات هزینه بالای خرید آن‌ها است.سیستم مدیریت قوانین کسب و کاربرای درک کارایی سیستم‌های مدیریت قوانین ابتدا باید بدانیم تعریف قوانین کسب و کارها چه چیزی را شامل می‌شود؟در اصل بعد از تعیین مسیرها و روندهایی که طی آن‌ها فرآیندهای کسب و کار شکل می‌گیرند، قوانین کسب و کار مانند تابلوهای کنار جاده هستند که به این مسیرها شکل می‌دهند و مراقب هستند که کسی از مسیر اصلی خارج نشود(در واقع ضوابطی که طی آن کسب و کارها به هدف تعیین شده می‌رسند).این قوانین دو قسمت دارند:1. شرط‌ها: که با استفاده از آن‌ها موقعیتی را ایجاد می‌کنیم تا عملیات مورد نظر انجام شود.2. اعمال: که ترسیم کننده فعالیت‌هایی است که باید در واکنش به شروط ارائه شده، انجام شوند.حال با شناخت کلی که از قوانین داریم می‌توانیم این نوع سیستم‌ها را تعریف کنیم: برعکس BPMS که تعریف کننده فرآیندها، شرایط و قوانین حاکم بر آن‌ها بودند، در BRMS سازمان‌ها از دل این قوانین توانایی خلق فرآیندها را ارائه می‌کنند.بنابراین یک BRMS تشکیل شده است از ۳ قسمت:· یک محیط توسعه جهت گسترش و خلق قوانین جدی متشکل از یک فضای low-cod,No-code تا هر فرد غیر فنی هم بتواند در آن فعالیت کند.· یک منبع کلی برای تمامی قوانین‌· یک موتور پردازش قوانین کسب و کار که به درخواست‌های همه سرویس‌ها پاسخ می‌دهد.مثال: یک شرکتی که سه نوع اشتراک برای کاربرانش ارائه می‌دهد را در نظر بگیرید: ابتدا قوانین دسته بندی هر کاربر بر اساس معیارها ثبت می‌شود. مثلاً: کاربران دارای سن بالای ۵۰ در گروه سوم قرار می‌گیرند.پس از ثبت قوانین و قرار گرفتن آن‌ها در مخزن قانون‌ها حال تمامی قسمت‌های سازمان می‌توانند از آن استفاده کرده و برای دسته بندی داده‌های ورودی خود آن را به کار گیرند.Message Queueصف پیام‌ها در اصل معماری ارائه می‌کند تا دیگر در زمان ارسال داده‌ها همه نودها یا مراکز انتقال داده به صورت بر خط آماده به کار نباشند زیرا این عمل بسیار هزینه بر است(چه از نظر مالی چه منابع دیگر) بنابراین روش کار به صورتی ایجاد می‌شود تا به جای فرآیند گفته شده در بالا پیام‌ها ارسال شده با گذر از تمامی مراکز در مقصد مورد نظر به صورت صف‌های ترتیبی(نوع صف بستگی به کاربری سیستم دارد) آماده استفاده از سوی مقصد شود.حال به طور کلی این معماری به سه قسمت تقسیم می‌شود:１- نقطه به نقطه: به صورتی که برنامه ارسال کننده به صورت پیش فرض اطلاعاتی از مقصد دارد و پیام‌ها را به مقصد ارسال می‌کند.２- Publish/subscribe: صادر کننده پیام به شکل کلی پیام‌ها را منتشر می‌کند و ممکن است یک یا چندین دریافت کننده در حال گوش دادن به پیام‌های ارسالی باشند و آن‌ها را دریافت کنند.３- درخواست/پاسخ: فرستنده به درخواست گیرنده داده ارسال می‌کند.(می‌تواند چندین بار داده‌ها منتقل شود.)Kafka یکی از ابزارهای مبتنی بر این معماری است که در دسته pub/sub قرار می‌گیرد. یکی از ویژگی‌های اصلی این ابزار استفاده از یک موتور تحلیلگر در میان ارسال پیام‌ها برای استفاده کننده است که در اصل موجب به وجود آمدن امکانات گسترده‌ای مانند: جداسازی و کاهش وابستگی میان بخش‌ها، ارائه موقعیت مکانی برخط(اجرای الگوریتم روی آن‌ها) و جمع آوری و دسته بندی داده‌های مرتبط می‌شود.از مزایای بسیار زیاد این فناوری می‌توان به جداسازی کامپوننت‌ها، افزایش قابلیت تغییر پذیری و استفاده مجدد اشاره کرد.Docker and Containerizationبرای تعریف مفهوم کانتینر باید به کاربرد و تفاوت آن با ماشین‌های مجازی در فرآیند انتشار و توسعه نرم‌افزار پرداخت به صورتی که می‌دانیم هر دوی آن‌ها انتزاعی هستند که در لایه برنامه کاربردی با جدا سازی و ایزوله کردن پکیج‌های کد باعث راحت‌تر شدن فرآیند توسعه و انتشار مداوم نرم‌افزار، استفاده راحت‌تر از DevOpsو در نتیجه افزایش چابکی در نرم می‌شوند. حال چرا در سال‌های اخیر استفاده از این مفهموم و فناوری‌های مختلف آن افزایش یافته است؟برخی مزایای کانتینرها نسبت به ماشین‌های مجازی به این صورت هستند:１- استفاده بهینه‌تر از حجم استفاده نشده منابع زیرساخت و تقسیم آن میان بخش‌هایی که نیاز به کمک دارند.２- حذف تکرارهایی که در ماشین‌های مجازی ایجاد می‌شود و همچنین باعث هدر رفت منابع می‌شود.３- آسان‌تر کردن ایجاد تغییرات و افزودن بخش‌های جدید به برنامه４- در اصل کانتینرها به مجازی سازی نرم‌افزارها می‌پردازند در صورتی که ماشین‌های مجازی همین کار را برای سخت‌افزار انجام می‌دهند.(سطح انتزاع بالاتر در کانتینرها)５- کاهش زمان غیر فعال بودن سرویس‌ها(down time) و همچنین کاهش زمان setup time که هر دو به بالا بردن میزان availability برنامه کمک می‌کنند.اما داکر با استفاده از این فناوری بستری با سرعت حداکثری ارائه می‌کند که در نتیجه آن توسعه دهندگان می‌توانند به آسان‌ترین روش ممکن برنامه‌های خود را در کانتینر قرار دهندن و همچنین از دیگر برنامه‌هایی که از این فناوری استفاده می‌کنند نیز با همان روش و عملکرد استفاده کنند. از مزایای داکر می‌توان به استقلال در اجرای برنامه اشاره کرد که یعنی تمامی پکیج‌هایی که هسته اصلی برنامه به آن‌ها وابستگی دارد همراه یکدیگر در هر زمان قابل دسترس هستند. همچنین در نتیجه موارد ذکر شده متوجه می‌شویم که حاصل استفاده از این تکنولوژی بدست آمدن نوعی برابری میان محیط تولید و توسعه نرم‌افزار می‌باشد.Container orchestrationاین فناوری در اصل برای خودکار سازی فرآیند گسترش کانتینرها، توسعه، مدیریت و ارتباط میان آن‌ها در سازمان‌های بزرگ که از تعداد زیادی سرویس پشتیبانی می‌کنند و قصد دارند در هر نسخه از انتشار محصولاتشان یک بار تمام این کانتینرها را راه‌اندازی کنند، استفاده می‌شود.از طرفی چون استقلال سرویس‌ها را افزایش می‌دهد بنابراین سازگاری بسیار بالایی با معماری میکروسرویس دارد زیرا به به هر سرویس شبکه، فضای ذخیره سازی و مدیریت مخصوص به خود آن سرویس را می‌دهد همچنین می‌توانیم با استفاده از آن کنترل بیشتری روی قسمت‌های مختلف برنامه در هر اجرا داشته باشیم و چرخه حیات هر کدام را زیر نظر بگیریم. در کل همه موارد بالا موجب می‌شود تا هماهنگی به وجود آمده کمک زیادی به اجرای فرآیند‌های DevOps، CI/CD و دستورات مدیریت API ها می‌کند.برخی موارد کاربری Container orchestration:１- پیکربندی و برنامه‌ریزی مناسب２- تخصیص منابع بهینه３- افزایش قابلیت فعال بودن کانتینر４- Load balancing and traffic routing５- بررسی لحظه‌ای سلامت کانتینرهاحال یکی از ابزارهای شناخته شده و open source که این فناوری را پیاده سازی می‌کند Kubernetes نام دارد که در واقع ویژگی اصلیش مدیریت و توسعه کانتینرهای برنامه‌هایی است که برای اجرا به چندین کنتینر همزمان نیاز دارند. در نتیجه Kubernetes بسیاری از فرآیندهای دستی را خودکار می‌کند و به دسته بندی کانتینرهایی که برای اجرا نیاز به یک مجموعه زیرساخت یکسان دارند کمک می‌کند.منابعhttps://blog.airbrake.io/blog/software-design/domain-driven-designhttps://medium.com/ssense-tech/hexagonal-architecture-there-are-always-two-sides-to-every-story-bc0780ed7d9chttps://blog.allegro.tech/2020/05/hexagonal-architecture-by-example.htmlhttps://learn.microsoft.com/en-us/azure/architecture/patterns/cqrshttps://microservices.io/patterns/data/cqrs.htmlhttps://ditty.ir/posts/mvvm-pattern/XpAPJhttps://learn.microsoft.com/en-us/xamarin/xamarin-forms/enterprise-application-patterns/mvvmhttps://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcinghttps://martinfowler.com/eaaDev/EventSourcing.htmlhttps://martinfowler.com/articles/micro-frontends.htmlhttps://www.techtarget.com/searchsoftwarequality/definition/low-code-no-code-development-platformhttps://www.nginx.com/learn/api-gatewayhttps://www.redhat.com/en/topics/api/what-does-an-api-gateway-do#overviewhttps://kissflow.com/workflow/bpm/business-process-management-overview/https://www.techtarget.com/searchcio/definition/Business-process-management-suite-BPMShttps://www.ibm.com/cloud/blog/business-rules-management-systems-101https://www.progress.com/faqs/corticon-faqs/what-is-a-business-rules-management-systemhttps://www.ibm.com/docs/en/ibm-mq/9.1?topic=overview-introduction-message-queuingwhat is kafka? - IBM Technology youtube channelhttps://www.docker.com/resources/what-containerhttps://enable.com/blog/introduction-to-docker-and-containerizationhttps://www.redhat.com/en/topics/containers/what-is-container-orchestration Sina Farahani Sina Farahani Mon, 28 Nov 2022 20:31:36 +0330