طراحی دامنه محور، رویکردی است که در آن ساختار و معماری سیستم نرم‌افزاری، به تبع حوزه مد نظر طراحی شود و در روند ایجاد ساختار و پاسخ به سوالات معماری، توجه اصلی، به دامنه کسب و کار باشد. به عبارتی میتوانیم بگوییم این رویکرد، دیدگاهی از بالا به پایین دارد. معمولا از این رویکرد در طراحی سیستمهای نسبتا بزرگ استفاده میشود. در این رویکرد لازم است تا در مورد دامنه مورد نظر دانش کافی داشته باشیم. دامنه یک سیستم، محدوده فعالیت و کاربرد آن سیستم است. مثلا دامنه فعالیت میتواند سفارش آنلاین غذا ( مانند اسنپ فود ) یا پلتفرم ارائه کتاب( مانند فیدیبو) باشد. گاهی ممکن است سیستم به قدری بزرگ باشد، که تقسیم کردن آن به بخش‌های کوچک‌تر امری منطقی باشد. مثلا پلتفرم دیجیکالا را میتوان به بخش فروش، پشتیبانی، ارسال و غیره تقسیم کرد. به عبارتی، محیطی که کسب و کار در آن فعالیت میکند به قدری بزرگ است که خود شامل موضوعات و بخش‌های مختلف است. در مواجهه با چنین مدل‌هایی تعریف مرز بین این محیط‌ها میتواند کمک کننده باشد. هر بخش در محیط جدا و برای دامنه‌ای خاص فعالیت میکند، به این رویکرد محیط مرز‌بندی شده میگویند. مثلا سیستم دانشگاه، شامل دامنه‌های مختلف هستند که هر کدام در محیطی جدا فعالیت میکنند، جدا کردن هر محیط در ایجاد ساختار مناسب تاثیر گذار خواهد بود. مثلا سیستم گلستان، شامل بخش آموزش، خوابگاه وغیره است. یکی دیگر از مزیت‌های DDD فراهم کردن امکان ارتباط بین Domain experts و developers است. DDD این کار با فراهم کردن یک زبان مشترک انجام میدهد. این زبان مشترک علاوه بر ارتباط بین توسعه دهنده و متخصص دامنه، در پیاده سازی سیستم هم استفاده میشود. یعنی برنامه نویس در نامگذاری اجزای کد، از همین زبان مشترک نیز استفاده میکند.[1][2]
ایده کلی این رویکر این است که منطق اصلی و دیگر قسمت‌ها ( ابزار‌ها، سرویس‌های خارجی، پایگاه داده، رابط کاربری و …) از یکدیگر مستقل کند. این کار با تقسیم سیستم به اجزای جدا ( اما مرتبط ) انجام میشود.به عبارتی این رویکرد شکلی از معماری لایهای است. در این رویکرد میخواهیم امکان تغییر و حایگزینی اجزای مختلف را بدون ایجاد تغییرات زیاد در دیگر بخش‌ها، بخصوص منطق اصلی داشته باشیم. در این رویکرد پیشنهاد میشود که ورودی و خروجی هر بخش، در لبه‌ی بیرونی تبادل شود و منطق پیاده سازی، وابسته نحوه‌ی ارائه خروجی ( مثلا Rest API یا GraphQL ) نباشد.
برای رسیدن به این هدف، این معماری ساختار از پورت و آداپتور استفاده میکند. هر کامپوننت، به وسیله تعدادی پورت با دیگر بخش‌ها ارتباط برقرار میکند. هم چنین برای بر قراری ارتباط از طریق یک پورت لازم است از پروتوکل تعریف شده توسط آن پورت تبعیت شود. هر کامپوننت خارجی میتواند به وسیله پورت و آداپتور مناسب آن با منطق مرکزی ارتباط برقرار کند ( مثلا هر دستگاه مختلف به شرط داشتن آداپتور USB میتوانند به یک کامپیوتر متصل شوند). علاوه بر پورت، هر کامپوننت شامل یک یا چند آداپتور نیز هست. آداپتور وظیفه ترجمه و تبادل داده بین هر کامپوننت و دیگر بخش‌ها را دارد. بسته به آنکه کامپوننت با چه بخش‌هایی تبادل اطلاعات دارد، میتوان چند آداپتور در نظر گرفت.[3][4][5]
در سیستمهای monolithic که از یک پایگاه‌داده مشترک استفاده میشود، هر دو عملیات نوشتن و خواندن توسط همان پایگاه‌داده پاسخ داده میشود. در شرایطی که سیستم نرم‌افزاری، سیستمی نسبتا کوچک باشد و با داده‌های زیادی مواجه نباشد، این عملیات‌ها دارای پیچیدگی قابل توجه نخواهند بود و مشکلی در مدیریت این عملیات‌ها ایجاد نمیشود. اما با بزرگ‌تر شدن سیستم، مدیریت پایگاه‌داده و اجرای عملیات نیز پیچیده‌تر خواهد شد. مثلا در یک پایگاه‌داده نسبتا بزرگ، برای خواندن داده توسط درخواست‌های نسبتا پیچیده ( مثلا join کردن چندین جدول ) ممکن است زمان قابل توجهی برای پردازش لازم باشد، و یا مثلا برای بروز رسانی جدول، ممکن است لازم باشد، اعتبار سنجی برای پیچیده‌ای برای نوشتن داده انجام شود، در این شرایط، با توجه به اینکه زمان پردازش میتواند نسبتا زیاد باشد، امکان قفل شدن پایگاه‌داده فراهم میشود.
رویکرد CQRS برای حل این مسئله پیشنهاد میدهد تا در سیستم مد نظر، دستور‌ها و کوئری ها از هم جدا شوند. دستورات عملیاتی هستند که تغییرات ایجاد میکنند، و بهتر است به صورت task-based باشند(update username ). همچنین کوئری‌ها فقط وظیفه جابجایی داده دارند و هیچ تغییری ایجاد نمیکنند. معمولا در این رویکرد، بجای استفاده پایگاه داده مشترک برای هر دو عملیات، از دو پایگاه داده جداگانه برای خواندن و نوشتن استفاده شود. در این حالت لازم است تا مکانیزمی برای sync کردن پایگاه‌داده‌ها در نظر گرفته شود.
مزیت این رویکرد این است که امکان مقیاس‌پذیری برای دو عملیات خواندن و نوشتن را مستقل از هم فراهم میسازد. همچنین به افزایش امنیت اطلاعات نیز کمک میکند، زیرا با این روش میتوان اطمینان حاصل کرد دستور نوشتن و ایجاد تغییرات، از مبدا معتبر انجام میشود.[6][7]
الگوی طراحی mvvm که توسط مایکروسافت ارائه شده است، روشی است اجازه میدهد تا منطق پیاده سازی، و ارائه و نمایش آن، از هم جدا باشد. در این الگو، سه مولفه اصلی وجود دارد. مولفه اول نما یا view نام دارد که وظیفه آن، تعریف ساختار رابط‌کاربری است. درواقع این مولفه اطلاعات را به کاربر نمایش میدهد. مولفه بعدی، مدل نام دارد. به طور خلاصه، مدل لایه‌ی داده در معماری است. مدل‌ها کلاس‌هایی هستند که وظیفه تعامل با اطلاعات را دارند. مدل و viewmodel در کنار هم عملیات تبادل ( خواندن و نوشتن ) داده را انجام میدهند. مولفه بعدی، Viewmodel نام دارد. به طور خلاصه، این مولفه ارتباط بین نما و مدل را فراهم میکند. در هر قسمت، با توجه به ورودی‌ای که از سمت نما وارد میشود، این مولفه ورودی را پردازش، و سپس با استفاده از مدل‌های مربوط، پاسخ مناسب را آماده و به بعنوان خروجی به نما میدهد. مزیت این رویکرد، مستقل کردن رابط کاربری، از منطق اصلی سیستم است. در این شرایط، امکان توسعه، تست و نگه‌داری هر مولفه به صورت جداگانه، توسط تیم‌های جداگانه فراهم میشود و به نوعی میتوان وابستگی بین بخش های سیستم را کاهش داد. این رویکرد در سیستمهای سرویس محور میتواند انتخاب مناسبی باشد.[8][9][10]
مفهوم الگوی Event Sourcing این است که به جای نگه‌داری حالت داده (state) فعالیت‌هایی که برای رسیدن به آن حالت انجام شده است نگه‌داری شود. بعنوان مثال، فرض کنید در سیستم بانکی، به جای آنکه باقی‌مانده حساب کاربر نگه‌داری شود، لیست تراکنش‌های آن حساب ذخیره شود. بدین ترتیب هر زمان که باقی‌مانده حساب لازم باشد، میتوان با استفاده از تراکنش‌ها، مقدار باقی مانده ( حالت کنونی) را بازیابی کرد. در این رویکرد بر خلاف حالت مرسوم که شامل ساختن، خواندن، بروز رسانی و حذف ( crud ) صرفا امکان ساختن و خواندن وجود دارد (CR). در مواقعی که با سیستمهای CRUD در نرمافزار با مقیاس بالا مواجه هستیم، نگه‌داری سیستم پیچیده‌تر خواهد بود و با محدودیت‌هایی روبرو خواهیم بود. مثلا در این سیستم‌ها بروز رسانی اطلاعات سربار زیادی خواهد داشت، که همین مورد مقیاس پذیری را تحت تاثیر قرار میدهد. و یا در سیستمهای پردازش موازی، امکان وقوع تعارض وجود دارد. برای حل این مشکلات، بخصوص در سیستمهای نسبتا بزرگ، رویکرد event sourcing میتواند کمک کننده باشد.[11][12]
معماری Micro frontend رویکردی است که در آن بخش Front End یک نرمافزار، به بخش‌های کوچک‌تر و مستقل از هم تقسیم میشوند. به عبارتی این رویکرد، یک پله از معماری micro Service فراتر رفته، و علاوه بر تقسیم کردن back end به بخش‌های مستقل، پیشنهاد میدهد تا بخش فرانت نیز از هم جدا باشد.
بدین ترتیب، هر قسمت میتواند جداگانه توسعه و نگه‌داری شود و این امکان وجود دارد در هر بخش از تکنولوژی متفاوت استفاده شود. همچنین با استفاده از این معماری، وابستگی بین بخش‌های متفاوت کم میشود، و هر بخش توسط تیم‌های جدا امکان پیاده سازی دارد. همچنین در این شرایط، امکان ایجاد تغییرات و افزودن ویژگی با سرعت بالا فراهم میشود. معماری میکروفرانت‌اند، ساختاری عمودی دارد، و هر بخش، بر دامنه‌ای خاص تمرکز دارد. بعنوان مثلا در یک سامانه فروش آنلاین، بخش پروفایل کاربر، سبد خرید، محصولات، جستجو و غیره را میتوان از هم جدا کرد.حتی در مواردی مانند SPA هر قسمت از یک صفحه میتواند به عنوان یک بخش مستقل در نظر گرفته شود. بدین ترتیب میتوان هر بخش از یک اپلیکیشن ( مانند پروفایل ) را بعنوان یک بخش مستقل در نظر گرفت، به عبارتی هر کدام از این مولفه هارا میتوان یک سرویس مستقل، با رابط کاربری مستقل در نظر گرفت.[13][14]
بستر‌های low-code امکانی را فراهم میکند، تا توسعه دهنده بدون نیاز به دانش فنی زیاد، و با استفاده از رابط کاربری، یک محصول نرم‌افزاری تولید کند. در این سیستم‌ها کاربر صرفا کامپوننت‌های مد نظر را کنار یکدیگر قرار میدهد، و خود سیستم تمامی بخش‌های مختلف، مانند فرانت‌اند و کد‌های بک‌اند را تولید میکند. مزیت قابل توجه این ابزار این است مدت زمان لازم برای توسعه محصول بسیار کاهش میابد. همچنین برای توسعه محصول با استفاده از این ابزار، دانش فنی کم‌تری لازم است، به همین جهت، افراد بیشتری میتوانند در روند توسعه محصول مشارکت داشته باشند. با توجه به این که این بستر‌ها، Reuseability بالایی دارند، علاوه بر افزایش سرعت توسعه، هزینه آن کاهش میابد. در مواقعی که یک سازمان، تیمی با توانایی لازم برای توسعه یک سیستم برای یک هدف خاص را نداشته باشدو یا مثلا تعداد توسعه دهنده کافی و یا زمان کافی نداشته باشد، و استخدام توسعه دهنده به صرفه نباشد، استفاده از این بستر‌ها انتخاب مناسبی است.
اما فقط در شرایط ذکر شده استفاده از این ابزار مفید نیست. در تیم‌ها و سازمان‌های بزرگ نیز استفاده از این بستر میتواند کمک کننده باشد. مثلا برای راه اندازی یک نمونه اولیه از محصول و فراهم کرد حلقه بازخورد سریع، میتوان از این بستر استفاده کرد.[15][16]
وظیفه اصلی EBS ارائه بستری، برای ایجاد ارتباط بین اجزا و سرویس‌های مختلف در معماری‌های سرویس‌گرا است. در این الگو، بستر ایجاد شده، علاوه برای ایجاد ارتباط بین مولفه‌ها، لازم است تا امکان جابجایی داده، تبدیل و ترجمه اطلاعات و مسیر یابی را فراهم سازد.
مزیت استفاده از این بستر در سیستمهای سرویس‌گرا، ساده سازی و یکپارچگی ارتباط بین سرویس‌های سازمان است. همچنین استفاده از این روش، در کاهش هزینه نیز تاثیرگذار خواهد بود، زیرا استفاده از این بستر بین سرویس‌ها مشترک خواهد بود، و لزومی ندارد برای ارتباط هر سرویس، پیاده سازی جدا صورت بگیرد. همچنین توسعه و نگه‌داری آن میتواند توسط یک تیم انجام بگیرد. استفاده از این بستر، مقیاس‌پذیری سیستم را نیز افزایش میدهد. به عبارتی، برخورداری از این الگو، سیستم را به یک Pluggable system تبدیل میکند و ارتباط سیستم کنونی با مولفه‌های جدید را ساده‌تر میکند. استفاده از تکنیک‌های مناسب در پیاده سازی بستر EBS بسیار اهمیت دارد. اگر در یک سیستم، این بستر از معماری مناسبی برخوردار نباشد و دارای صفات کیفی قابل قبول نباشد، به راحتی میتواند کارایی کل سیستم را تحت تاثیر قرار دهد. به عبارت دیگر، اگر EBS کارایی کافی نداشته باشد، تبدیل به bottleneck سیستم میشود، کارایی کل سیستم را کاهش میدهد. به همین جهت اگر معماری مناسب در طراحی آن اتخاذ نشده باشد، بهبود و ایجاد تغییرات در آن، ممکن است هزینه زیادی لازم داشته باشد.[17][18]
در سیستم‌هایی که معماری میکروسرویس دارند، رویکرد مناسب استفاده از API Gateway میباشد. به طور خلاصه، api gateway نقطه ورودی سیستم برای اتصال به هر سرویس است. به عبارت دیگر، api gateway لایهای است که بین کلاینت و سرویس‌ها قرار میگیرد و ارتباط بین این دو را برقرار میکند. کاربران برای استفاده از سرویس مد نظر، درخواست خود را به این لایه ارسال میکنند و سپس با بررسی درخواست، به سرویس مناسب ارسال میشود.
نکته قابل توجه این است که ممکن است api gateway به دلیل افزایش سرویس‌ها، بزرگ‌تر و پیچیده‌تر، و در نتیجه نگه‌داری آن سخت‌تر شود. به همین جهت پیشنهاد میشود تا خود API Gateway نیز دسته‌بندی شود.
مثلا اگر سیستم در دو نسخه متفاوت برای مبایل و وب ارائه شده است، و هر کدام از سرویس‌های متفاوت استفاده میکنند، میتوان دو Gateway جدا برای هر کدام در نظر گرفت. استفاده از api gateway در سیستمهای سرویس گرا امری ضروری است. اگر این لایه برای ارتباط وجود نداشته باشد، هر کلاینت برای استفاده از یک سرویس باید مستقیما به endpoint آن متصل شود. در این شرایط نگه‌داری سیستم پیچیده‌تر و پرهزینه‌تر خواهد بود و در ایجاد تغییر و یا اضافه کردن سرویس جدید، با چالش مواجه خواهیم بود. به همین جهت، وجود یک لایه میانی، که ارتباط بین کلاینت و سرویس‌ها را برقرار کند، میتواند کمک کننده باشد.[19]
سیستم مدیریت فرایند کسب و کار، بستری است که در آن امکان طراحی، مدل سازی، توسعه و نگه‌داری فعالیت‌های کسب و کار وجود دارد.در این بستر، میتوان هر فرایند سازمانی که توسط هر فرد و یا هر بخش سازمان اجرا میشود را مدل کرد. همچنین این سیستم امکان ایجاد و انجام فرایند سازمانی به صورت خودکار را فراهم می‌آورد. این بستر، امکان بررسی دقیق فرایند‌ها برای عیب‌یابی را فراهم میکند و کمک میکند تا مواردی که ممکن است منجر به خطا شود ( مثلا bottleneck فرایند) شناسایی شود. با رفع این ایرادات میتوان از افزایش هزینه‌ها جلوگیری کرد. دیگر مزیت این بستر، افزایش کارایی میباشد، زیرا با خودکار شدن این روند، از انجام کار‌های تکراری جلوگیری میشود. همچنین بهره‌مندی از این پلتفرم در معماری، چابکی سیستم را نیز به نحوی افزایش میدهد، زیرا با استفاده از این ابزار، میتوان در حین اجرای فرایند، آنرا ارزیابی نمود و برای بهبود آن تکنیک‌های لازم استفاده شود، به عبارتی، چرخه بازخورد به نوعی سریع‌تر خواهد بود
به طور خلاصه در این سیستم‌ها، میتوان پیچیده ترین فرایند سازمانی را مدل‌سازی کرد، و سپس با اجرای آن در این بستر، روند اجرای آن را تحت نظر قرار داد و در صورت نیاز تصمیمات لازم را اتخاذ نمود تا فرایند، بیشترین سود‌دهی را داشته باشد. همچنین در این سیستم، امکان ایجاد تغییرات در یک فرایند، به نحوی که سبب بهبود خروجی آن شود وجود دارد.[20][21]
سیستم مدیریت قوانین کسب و کار، بستری است که در آن فرایند تعریف و طراحی، توسعه ، راه‌اندازی و مدیریت و نگه‌داری قوانین کسب و کار به صورت خودکار انجام میشود. قوانین کسب و کار معرف یک کسب و کار هستند. به عبارت دیگر، هر فرایند در یک کسب و کار برای به هدف رسیدن و سودآوری، نیاز‌مند اتخاذ یکسری تصمیم است، قوانین کسب و کار، چارچوبی هستند که به کمک آن‌ها میتوان تصمیم مناسب برای به هدف رسیدن فرایند اتخاذ کرد. معمولا قوانین کسب و کار شامل دو مولفه اصلی هستند، شرایط و عمل. مثلا در سیستم دانشگاه، در شرایطی که نمره دانشجو کم‌تر از حد قابل قبول باشد ( شرایط ) لازم است فرایند مردود شدن دانشجو در آن درس اعمال شود ( عمل ). با استفاده از BRMS فرایند ایجاد و اجرای قوانین کسب و کار، به صورت خودکار انجام خواهد شد. مزیت استفاده از این بستر در معماری سازمان، افزایش کارایی علاوه بر کاهش هزینه است، زیرا فرایند مدیریت قوانین، به صورت خودکار انجام میشود. همچنین مقیاس‌پذیری سیستم افزایش خواهد یافت، چون افزودن قوانین جدید، از مرحله طراحی تا توسعه و راه‌اندازی به صورت خودکار و با سرعت بالا امکان‌پذیر خواهد بود، همچنین با استفاده از این ابزار، مشکلاتی مانند ایجاد تعارض در قوانین به راحتی قابل مشاهده خواهد بود، به همین علت، نگه‌داری سیستم نیز بهبود خواهد یافت. دیگر مزیت بهره‌مندی از این بستر، افزایش امنیت سیستم است، زیرا در این شرایط، میتوان دسترسی به قوانین کسب و کار، که به عبارتی هسته مرکزی سیستم نرم‌افزاری هستند را محدود‌تر نمود.[22][23]
به طور کلی صف پیام یک مکانیزم برای برقراری ارتباط بین چندین مولفه میباشد. در این رویکرد، یک صف برای پیام‌ها در نظر میگیریم که زمانی که یک مولفه نیاز به ارسال درخواست به یک مولفه دیگر را داشته باشد پیام خود را در این صف قرار میدهد. در برخی روش‌ها، برای برقراری ارتباط بین دو مولفه، یک کامپوننت پس از ارسال درخواست، باید در انتظار پاسخ آن بماند. حال اگر از معماری سرویس محور استفاده کنیم، در این شرایط، هر سرویس برای دریافت پاسخ باید در انتظار یک مولفه دیگر بماند و با توجه به این که در این شرایط ممکن است تعداد قابل توجهی از سرویس‌ها نیاز به پاسخ سرویس دیگر داشته باشند کارایی سیستم کاهش خواهد یافت. در این شرایط استفاده از صف پیام میتواند مفید باشد. این صف بعنوان یک حافظه موقت عمل میکند که در آن درخواست یک کلاینت و یا یک کامپوننت ذخیره میشود.
در این رویکرد معمولا دو عنوان تعریف میشود، تولید کننده پیام و مصرف کننده. تولید کننده در واقع همان کلاینت است که درخواستی برای پردازش دارد و مصرف کننده عامل پاسخ دهنده به آن است. تولید کننده با اتصال به اند‌پوینت صف، پیام و یا درخواست خود را در صف قرار میدهد. پیام‌ها به ترتیب از ابتدای صف به مصرف کننده مناسب برای پردازش ارائه میشود و پس از پردازش آن یک پاسخ مناسب آماده میکند. با توجه به این که اولویت کار‌ها میتواند متفاوت باشد، میتوان چندین صف پیام در نظر گرفت.[24][25]
مفهوم containerization بسته‌بندی کد و وابستگی‌های آن به همراه محیط اجرایی که نرمافزار در آن تست و اجرا شده است، میباشد. به طور معمول در روش‌های سنتی، برای توسعه و پیاده سازی محصول، کد و پیاده سازی سیستم، در محیطی مستقل انجام میشود و خروجی آن در محیطی دیگر راه‌اندازی میشود. در این حالت امکان وقوع خطاها‌یی به علت عدم رعایت وابستگی به وجود می‌آید. برای بر طرف کردن این چالش، میتوان از containerization استفاده کرد. این رویکرد با بسته‌بندی کردن تمام وابستگی‌ها، نرمافزار و پیکر‌بندی‌های لازم برای اجرا، به چالش‌هایی که در مرحله deployment ممکن است به وجود بیاید را پاسخ میدهد. مزیت استفاده از این ابزار، قابل حمل بودن محصول نهایی است. در این الگو، محصول نهایی یک پکیج قابل اجرا خواهد بود که وابستگی به محیطی که قرار است در آن deploy شود نخواهد داشت. همچنین، با توجه به این که هر کانتینر، مستقل از دیگر کانتینینر‌ها است، وقوع خطا در یکی از آن‌ها، سبب ایجاد مشکل در دیگر کانتینر‌ها نخواهد شد، همین جهت امنیت سیستم افزایش خواهد یافت.
یکی از ابزاری که در این حوزه محبوبیت بالایی دارد ابزار Docker است. این بستر میتواند یک سیستم به همراه همه‌ی وابستگی‌های آن را در یک پکیج ارائه دهد که امکان راه‌اندازی بر روی هر نسخه از لینوکس، ویندوز و مک‌او‌اس را دارد.[26][27]
هماهنگی کانتینر‌ها فرایندی است که در آن عملیات لازم برای استفاده از کانتینر‌ها، شامل راه‌اندازی، مدیریت و مقیاس‌دهی را به صورت خودکار انجام دهد. معمولا از این مفهوم، برای راه‌اندازی، مدیریت، زمانبندی، تخصیص منابع و مانیتورینگ استفاده میشود. در سازمان‌ها و سیستم‌هایی که از تعداد قابل توجی کانتینر استفاده میکنند، استفاده از این تکنیک میتواند کمک کننده باشد.[28]
مدیریت لاگ، فرایندی است که در آن جمع‌آوری، ذخیره و پردازش لاگ، به صورت مداوم و حتی خودکار انجام شود. لاگ سیستم، تاریخچه‌ای از رخداد‌هایی است که توسط کد سیستم تولید میشوند. تولید و مگه‌داری لاگ سیستمهای نرم‌افزاری امری ضروری است. مثلا پس از وقوع خطا، میتوان با مراجعه به لاگ سیستم، علت را جویا شد، و از دوباره رخ دادن آن خطا جلوگیری کرد. لاگ میتواند به صورت یک فایل، شامل پیام، تعاملات کاربران و یا گزارش خطا باشد. استفاده از ابزار مدیریت لاگ، فرایند تولید و ذخیره لاگ به صورت خودکار انجام میدهد. مدیریت لاگ سیستم نرم‌افزاری شامل فرایند‌های مختلفی است. اولین فرایند، جمع‌آوری (Collecting)داده است. ابزار مدیریت لاگ، اطلاعات لازم را از مولفه های مورد نظر ( سرور، کاربر، سرویس‌ها) جمع‌آوری میکند. مورد دیگر، نظارت بر لاگ‌ها است. با نظارت بر لاگ، میتوان از وقوع خطا جلوگیری کرد. این ابزار‌ها میتوانند با نظارت بر لاگ‌ها، به برخی از رخداد‌ها واکنش نشان دهند. مثلا با بررسی لاگ، سربار سرور را نظارت شود و در صورت وقوع ناهنجاری، هشدار صادر کند. همچنین معمولا ابزار مدیریت لاگ، امکان تحلیل رخداد‌های سیستم را نیز دارند. در مدیریت لاگ سیستم، معمولا با چالش‌هایی نیز مواجه هستم. مثلا در سیستمهای بزرگ ممکن است حجم داده مربوط به لاگ زیاد باشد و پردازش آن با مشکل مواجه شود. همچنین لاگ تولید شده توسط سیستم، اگر ساختار مناسب نداشته باشد، پردازش آن ممکن است با چالش مواجه شود.[30]
ابزار مانیتورینگ، ابزار‌هایی هستند که برای بررسی وضعیت بخش‌های مختلف سیستم مورد استفاده قرار میگیرند. استفاده از این ابزار مزیا زیادی دارد. مثلا با نظارت حالت سیستم، میتوان قبل از وقوع خطا، احتمال وقوع آن را پیشبینی کرد. معمولا این کار با لاگ کردن رخداد‌ها و تحلیل آن‌ها به کمک ابزار مدیریت لاگ، صورت میگیرد. استفاده از ابزار مانیتورینگ، سبب میشود تا در موارد ضروری ( مانند وقوع خطا) تصمیمات لازم برای مقابله با آن گرفته شود. همین امر سبب میشود تا کارایی و Availability سیستم افزایش یابد.
تحلیل کد ایستا، رویکردی است برای تحلیل و رفع خطا‌های کد، بدون اجرا کردن آن. در واقع در این روش، ساختار کد بررسی میشود و ضعف‌های آن بدون نیاز به اجرای کد تحلیل میشود. معمولا ابزار‌های تحلیل به صورت خودکار کد را بررسی میکنند مواردی مانند خطا‌های برنامه نویسی، عدم رعایت استاندارد‌های برنامه نویسی، خطا‌های سینتکس و مواردی مانند ضعف‌های امنیتی را گزارش میکنند. میتوان این بررسی را در خط لوله تحویل محصول انجام داد. با توجه به این که در چرخه توسعه محصول، تعداد دفعات build کردن کد زیاد است، استفاده از ابزار‌های خودکار برای این کار انتخاب مناسبی است. معمولا این ابزار تحلیل‌های مختلفی انجام میدهند. مثلا تحلیل کنترل برنامه، که در آن ساختار روند اجرا بررسی میشود. و یا تحلیل داده و متغییر‌های کد. استفاده از این ابزار، چرخه بازخورد را نیز کوتاه‌تر کرده و کارایی سیستم را افزایش میدهد.[31]
رویکرد تحویل مستمر، روشی است که در آن تلاش میشود تا فاصله بین تغییر در کد و اعمال آن در محصول نهایی کاهش یابد. معمولا این روش با خودکار کردن روند build، تست، پیکر‌بندی و راه‌اندازی انجام میشود و معمولا از یک خط لوله برای اجرای آن استفاده میشود. میتوان گفت این رویکرد، یکی از مهم‌ترین نیاز‌مندی‌های سیستمهای نرم‌افزاری در سازمان‌ها است. در روش‌های سنتی که از CD استفاده نمیشد، در بسیاری از موارد، چرخه تحویل محصول یکی از گلوگاه‌های سیستم بود. در این شرایط، تیم مربوطه میبایست، به صورت دستی تمام مراحل ساخت، تست و راه‌اندازی را انجام میداد و به همین علت، امکان وقوع خطا بسیار بود. اما با وارد شدن CD به تکنیک‌های معماری، این چالش حل شد. استفاده از CD، روند فرایند تحویل را به صورت خودکار انجام میدهد، در این شرایط علاوه بر کاهش احتمال خطا، چرخه تحویل نیز کوتاه‌تر خواهد بود. نکته دیگر این است که، بر خلاف گذشته، امروزه در روند توسعه و نگه‌داری یک نرمافزار، شاید لازم بایشد در طول روز به تعداد دفعات زیاد، تغیراتی که در کد ایجاد میشود بر روی محصول نهایی اعمال شود و به عبارتی کد build شود.[32][33]
با توجه به این که امروزه بسیاری از پلتفرم‌ها و سازمان‌ها چندین سرویس متفاوت ارائه میدهند، یکی از چالش‌هایی که بوجود می‌آید بحث احراز هویت کاربران است.
به طور کلی، مدیریت هویت رویکردی است که با استفاده از آن میتوان اطمینان حاصل کرد که به فرد اشتباه دسترسی داده نمیشود. به عبارت دیگر مشخص میکند یک کاربر کیست و چه کاری میتواند انجام دهد و به چه منابعی دست رسی دارد. یکی از جنبه های مهم در این موضوع SSO است. در هر سیستم و یا سازمان، کاربر باید برای استفاده از هر سرویس یا منابع سازمان، احراز هویت انجام دهد. مثلا فرض کنید در یک سازمان، لازم باشد، یک کارمند برای استفاده از منابع و یا فرایند‌های مختلف احراز هویت شود. و یا ممکن است در یک سیستم سرویس محور، برای استفاده از هر سرویس، احراز هویت لازم باشد، در این شرایط کاربر باید برای ارتباط با هر مولفه عملیات احراز هویت انجام دهد.
این موضوع میتواند سبب کاهش تجربه‌کاربری در استفاده از یک پلتفرم شود. به همین علت، موضوع احراز هویت یکپارچه مطرح میشود. در این رویکرد، کاربر یکبار احراز هویت میشود و میتواند از همه‌ی سرویس‌ها استفاده کند. مثلا کاربر با وارد شدن به حساب کاربری جیمیل، حساب کاربری شخص در دیگر سرویس‌های گوگل نیز احراز هویت میشود.[34]
1. https://en.wikipedia.org/wiki/Domain-driven_design
2. https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/february/best-practice-an-introduction-to-domain-driven-design
4. https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)
5.https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749
6.https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs
8.https://learn.microsoft.com/en-us/xamarin/xamarin-forms/enterprise-application-patterns/mvvm
9.https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
10.https://www.geeksforgeeks.org/mvvm-model-view-viewmodel-architecture-pattern-in-android/
11.https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing
12.https://medium.com/design-microservices-architecture-with-patterns/event-sourcing-pattern-in-microservices-architectures-e72bf0fc9274
13.https://micro-frontends.org/
15.https://theecmconsultant.com/best-low-code-platforms/
16.https://en.wikipedia.org/wiki/Low-code_development_platform
17. https://www.ibm.com/cloud/learn/esb
18.https://en.wikipedia.org/wiki/Enterprise_service_bus
20. https://kissflow.com/workflow/bpm/business-process-management-systems-top-features/
21.https://en.wikipedia.org/wiki/Business_process_management
22. https://www.ibm.com/cloud/blog/business-rules-management-systems-101
23. https://en.wikipedia.org/wiki/Business_rule_management_system
24.https://aws.amazon.com/message-queue/
25.https://en.wikipedia.org/wiki/Message_queue
26.https://www.ibm.com/cloud/learn/containerization
27.https://www.redhat.com/en/topics/cloud-native-apps/what-is-containerization
29.https://www.redhat.com/en/topics/containers/what-is-container-orchestration
30.https://www.crowdstrike.com/cybersecurity-101/observability/log-management/
31.https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis#:~:text=Static%20analysis%2C%20also%20called%20static,code%20adheres%20to%20industry%20standards.
32. https://learn.microsoft.com/en-us/devops/deliver/what-is-continuous-delivery
33. https://en.wikipedia.org/wiki/Continuous_delivery
34.https://www.cloudflare.com/learning/access-management/what-is-sso/
35.https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
