تعاریف واژگان معماری نرم افزار

طراحی دامنه محور :

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

فرض آن این است:

· تمرکز اصلی پروژه را روی دامنه اصلی و منطق دامنه قرار دهید

· طرح های پیچیده را بر روی یک مدل قرار دهید

· همکاری خلاقانه بین متخصصان فنی و حوزه را آغاز کنید تا به طور مکرر به قلب مفهومی مشکل نزدیک‌تر شوید.

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

دامنه چیست؟

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

قوانین کلی هنگام طراحی مدل

1. روی حوزه اصلی تمرکز کنید

2. طراحی یک مدل در یک همکاری خلاقانه بین افراد دامنه و افراد نرم افزار

· طراحی توسط کسب و کار

o وابستگی های قوی بین هر دامنه مجاز نیست، از برخورد جلوگیری می کند و استقلال را ارتقا می دهد.

· جفت شدن آزادانه بین دامنه ها

o وابستگی های قوی بین هر دامنه مجاز نیست، از برخورد جلوگیری می کند و استقلال را ارتقا می دهد.

· از چرخه های زندگی مستقل اطمینان حاصل کنید

o اطمینان حاصل کنید که هر خط از کسب و کار ترجمه شده به دامنه، دارای یک چرخه زندگی واضح و جدا شده است

3. به زبانی همه جا صحبت کنید تا همه ذینفعان به طور کامل یکدیگر را درک کنند و بتوانند به طور موثر کار کنند

معماری شش ضلعی :‌

معماری شش ضلعی استقرار برنامه ها را بدون رابط کاربری یا پایگاه داده آنها تسهیل می کند - و آنها را قادر می سازد جدا از محیط تکنولوژیکی خارجی اجرا شوند. ماهیت معماری شش ضلعی جداسازی هسته سیستم از دنیای بیرونی است. این یک مشکل کلیدی را حل می کند - آزمایش پذیری معماری. معماری شش ضلعی ما را قادر می سازد تا برنامه های کاربردی قابل آزمایش را از طریق وارونگی وابستگی بسازیم.

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

• ابتدا لایه پایگاه داده را پیاده سازی کنید - پایگاه داده قلب سیستم است
• دوم، لایه منطق تجاری را پیاده سازی کنید، که به لایه پایگاه داده بستگی دارد - لایه منطق تجاری داده ها را از پایگاه داده می خواند، منطق تجاری را انجام می دهد و داده ها را در پایگاه داده ذخیره می کند.
• ثالثاً، لایه ارائه را پیاده سازی کنید، معمولاً برخی از UI، که به لایه منطق تجاری اشاره می کند، اما ممکن است مستقیماً به لایه پایگاه داده نیز ارجاع دهد.

تنها راهی که می‌توانیم برنامه را اجرا کنیم (و آزمایش کنیم) با پایگاه داده و رابط کاربری است. برنامه به نگرانی های تکنولوژیکی بستگی دارد. این باعث دو مشکل می شود:

• زمانی که برنامه ما نیاز به کار با فناوری ارائه دیگری دارد، دوباره کاری گران قیمت است
• زمانی که برنامه ما نیاز به تغییر به فناوری پایگاه داده دیگری دارد، دوباره کاری گران قیمت است

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

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

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

در معماری شش ضلعی، ما از اصل وارونگی وابستگی (DIP - مانند SOLID) استفاده می کنیم تا برنامه را از نگرانی های تکنولوژیکی خارجی جدا کنیم، به طوری که بتوانیم برنامه را به صورت مجزا از UI و پایگاه داده، شبکه اجرا کنیم (و آزمایش کنیم). و هر گونه نگرانی فنی معماری دیگر. ما در حال آزمایش رفتار برنامه به صورت مجزا و بدون هیچ فناوری هستیم.

با معکوس کردن وابستگی ها در معماری لایه ای سنتی، معماری نشان داده شده در شکل را دریافت می کنیم.

به طور رسمی تر، هدف اساسی معماری شش ضلعی این است که «برنامه خود را ایجاد کنید تا بدون رابط کاربری یا پایگاه داده کار کند تا بتوانید تست های رگرسیون خودکار را در برابر برنامه اجرا کنید، زمانی که پایگاه داده در دسترس نیست کار کنید، و برنامه ها را بدون هیچ کاربری به یکدیگر پیوند دهید. مشارکت" و هدف معماری شش ضلعی این است که "اجازه می دهد یک برنامه کاربردی به همان اندازه توسط کاربران، برنامه ها، اسکریپت های آزمایشی یا دسته ای خودکار در سمت سرور قرار گیرد و جدا از دستگاه ها و پایگاه داده های زمان اجرا نهایی آن توسعه و آزمایش شود" ( آلیستر کاکبرن، https://alistair.cockburn.us/hexagonal-architecture/).

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

الگوی CQRS :

Command Query Responsibility Segregation (CQRS) یک الگوی معماری نرم افزار است که مسئولیت های خواندن و نوشتن داده ها را در یک سیستم از هم جدا می کند. در CQRS، سیستم به دو بخش مجزا تقسیم می‌شود، یک سمت فرمان و یک سمت پرس و جو، که هر کدام مجموعه‌ای از مسئولیت‌ها و ساختار داده‌های خاص خود را دارند.

مزایا

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

مزیت دیگر CQRS این است که امکان مدیریت آسان منطق تجاری پیچیده را فراهم می کند. از آنجایی که سمت Command مسئول اعتبارسنجی و اجرای دستورات است، می‌تواند قوانین پیچیده تجاری و اعتبارسنجی را بدون تأثیر بر عملکرد سمت Query مدیریت کند.

معایب

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

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

معماری MVVM :

کلید درک معماری MVVM درک چگونگی تعامل سه جزء کلیدی در MVVM با یکدیگر است. از آنجایی که View فقط با ViewModel و ViewModel فقط با Model ارتباط برقرار می کند.

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

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

مزایای MVVM

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

· تست آسان تر: یکی از سخت ترین چیزهایی که در یک برنامه آزمایش می شود، رابط کاربری (UI) است. از آنجایی که ViewModel و Model کاملا مستقل از View هستند، توسعه دهندگان می توانند بدون نیاز به استفاده از View برای هر دو تست بنویسند.

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

معایب MVVM

جان گوسمن، معمار مایکروسافت که اولین بار MVVM را معرفی کرد، معایب اصلی الگو را موارد زیر می داند:

· پیچیدگی: MVVM در ایجاد رابط های کاربری ساده بسیار زیاد است. هنگام کار بر روی پروژه‌های بزرگ‌تر، طراحی ViewModel به منظور دستیابی به میزان کلی کلی می‌تواند بسیار دشوار باشد.

· اشکال زدایی دشوار است: از آنجایی که اتصال داده ها به صورت اعلانی است، اشکال زدایی آن نسبت به کدهای سنتی و ضروری دشوارتر است.

معماری event sourcing :

Event Sourcing یک الگوی معماری است که امکان توسعه بسیار کارآمد معماری های رویداد محور را فراهم می کند. در الگوی طراحی، دو نوع وجود دارد: الگوهای تاکتیکی و الگوهای معماری. الگوهای تاکتیکی الگوهای ساختار، رفتار و خلقت هستند. الگوهای ساختار بهترین راه را برای اتصال اشیا نشان می‌دهند تا به آنها اجازه دهد مستقل از تحولات آینده تکامل یابند، به عنوان مثال، چگونه می‌توان برنامه‌ای ایجاد کرد که برای اصلاح بسته و باز است؟ الگوهای رفتاری نشان می‌دهند که چگونه اشیا باید با هم تعامل داشته باشند تا بتوانند یک مشکل را به بهترین شکل حل کنند، و الگوهای ایجاد نشان می‌دهند که بهترین راه برای ایجاد اشیا چیست. الگوهای معماری برای بهبود کیفیت، کارایی و قابلیت اطمینان نرم افزار توسعه استفاده می شود. می‌توانیم الگوی MVC، وارونگی کنترل، تزریق وابستگی، CQRS و منبع‌یابی رویداد را ذکر کنیم. به عنوان مثال، الگوی MVC امکان توسعه لایه ارائه یک برنامه کاربردی را فراهم می کند، این الگو بر اساس الگوهای تاکتیکی زیادی است.

Event Sourcing یک الگوی معماری است که شامل ثبت تمام تغییرات حالت یک برنامه کاربردی به عنوان دنباله ای از رویدادها است. این به این معنی است که در یک برنامه، شما نباید روی وضعیت فعلی برنامه تمرکز کنید، بلکه باید تمام رویدادهایی را که در آنجا رخ داده است و به برنامه اجازه می دهد در وضعیت فعلی خود باشد را ثبت کنید. بنابراین مهم است که روی توالی تغییرات حالت (رویدادهای تجاری) که منجر به وضعیت فعلی برنامه می شود، تمرکز کنیم.

مثال :

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

از توالی رویدادها، می توانیم وضعیت فعلی برنامه را جمع آوری کنیم. و این اصل Event Sourcing است که در آن هر تغییر در حالت یک علت واحد دارد.

معماری Micro Frontends :

هنگامی که رویکرد میکروسرویس را به سمت جلو می‌آوریم، Microfrontends چیزی است که به دست می‌آوریم. به عبارت دیگر، یک microfrontend از اجزایی ساخته شده است - متعلق به تیم های مختلف - که می توانند به طور مستقل مستقر شوند. این اجزا برای ایجاد یک تجربه کاربری ثابت مونتاژ شده اند.

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

پلتفرم توسعه کم کد:

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

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

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

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

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

درگاه سرویس سازمانی یا ESB :

در دنیای امروزی از برنامه های کاربردی پیچیده و متفاوت، معمول است که داده ها در یک برنامه (مانند برنامه مالی شما) ذخیره می شود که در چندین برنامه دیگر (مانند قراردادها یا برنامه های منابع انسانی شما) نیز مورد نیاز است. این اغلب با انتقال داده های دسته ای بین برنامه ها برطرف می شود. متأسفانه، این معمولاً شامل فرآیندهای دستی است که مستعد خطا هستند، که اغلب می‌تواند منجر به اطلاعات قدیمی یا «کهنه» در سیستم‌های اصلی شود که برای عملیات خود به آنها اعتماد می‌کنید.

Enterprise Service Bus یا ESB یک راه‌حل فناوری ایده‌آل است که می‌تواند به شما در غلبه بر چالش‌های یکپارچه‌سازی داده‌ها و خدمات در سراسر سازمانتان کمک کند.

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

API Gateway :

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

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

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

یک دروازه API چگونه کار می کند؟

دروازه API یک نقطه یک ورودی است که در مقابل یک API قرار دارد. امنیت API را برای میکروسرویس ها (که می توانند داخلی و خارجی باشند) و API های back-end تعریف شده اعمال می کند. دروازه API همچنین در دسترس بودن و مقیاس پذیری بالا را تضمین می کند.

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

سامانه مدیریت فرآیند های کسب و کار یا BPMS :

مدیریت فرآیند کسب و کار روشی است که تیم شما را کارآمد و کسب و کار شما را رقابتی نگه می دارد.

سازمان‌هایی که رویه‌های مشخصی ندارند، با تأخیرهای عملیاتی، تهدیدات امنیتی و فرآیندهای گیج‌کننده‌ای مواجه می‌شوند که بر نتایج آنها تأثیر می‌گذارد. استراتژی های BPM مناسب به تیم های شما اجازه می دهد تا مسئولیت های خود را به موقع انجام دهند و نتایج سریع تری را تجربه کنند.

BPM ایجاد، بهینه سازی، اجرا و ارزیابی فرآیندهای خاص در یک سازمان است.

نظم BPM را می توان برای فعالیت های عملیاتی که تکراری، مداوم و قابل پیش بینی هستند به کار برد. با BPM، سازمان‌ها می‌توانند این فعالیت‌ها را ساده‌سازی کنند تا تیم‌هایشان بتوانند به نقاط عطف تجاری دست یابند، هزینه خطا را کاهش دهند و تجربیات عالی برای مشتری ارائه دهند.

BPM می تواند به سازمان ها در دستیابی به اهداف تجاری در بخش ها و عملکردهای مختلف کمک کند. این شامل:

· حساب‌های پرداختنی و دریافتنی: تسریع در بررسی و تأیید فاکتورها، کاهش تأخیر پرداخت‌ها با نظارت قابل مشاهده و پیگیری آسان‌تر

· منابع انسانی (HR): استخدام کارکنان جدید، خودکار کردن مسیریابی اسناد

· انطباق و مدیریت ریسک: شناسایی ریسک های قانونی و مالی، اطلاع رسانی به تیم های حسابرسی داخلی برای پیگیری و حل مسائل

سامانه مدیریت قوانین کسب و کار یا BRMS :

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

چالش کسب و کار

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

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

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

· حکمرانی ضعیف: ممیزی های داخلی و مقررات دولتی ایجاب می کند که بر رفتار شرکت خود کنترل داشته باشید، که مستلزم درک قوانین کسب و کارتان است.

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

صف پیام :

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

صف پیام چیست؟

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

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

یک شکل ناهمزمان از ارتباط که در آن یک برنامه یا شخص پیامی را به برنامه یا شخص دیگری ارسال می کند، اما منتظر پاسخ یا تأیید فوری نیست.

داکر و کانتینرسازی :

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

فلسفه ما ایجاد سیستم هایی است که بر توسعه یک برنامه واحد متمرکز هستند. منظورم این است که ما می خواهیم با یک یا شاید دو پروژه منحصر به فرد کار کنیم و اجازه دهیم بقیه برنامه های ما به ابر منتقل شوند. ما تمایل داریم این برنامه ها را به اجزای ایزوله و کپسوله ای تقسیم کنیم که منابع مشترکی ندارند. این فرآیند تقسیم یک Dockerfile و یک تعریف ساخت مبتنی بر برنامه ایجاد می کند که با استفاده از ابزارهایی مانند Docker Compose مستقر می شود.

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

· ذخیره یک دسته از کانتینرها

· به اشتراک گذاری منابع انعطاف پذیر

· مقیاس پذیری - بسیاری از کانتینرها را می توان در یک میزبان قرار داد

· سرویس خود را روی سخت افزاری اجرا کنید که بسیار ارزان تر از سرورهای استاندارد است

· استقرار سریع، سهولت ایجاد نمونه‌های جدید و مهاجرت سریع‌تر.

· سهولت جابجایی و نگهداری برنامه های کاربردی شما

· امنیت بهتر، دسترسی کمتر مورد نیاز برای کار با کدهای در حال اجرا در داخل کانتینرها، و وابستگی کمتر نرم افزاری

هنگام ایجاد زیرساخت کانتینری لازم برای ساخت برنامه های کاربردی در فضای ابری، این مزایای Docker را در نظر داشته باشید. فلسفه ما شامل استفاده از کانتینرهای Docker برای بسیاری از برنامه هایمان است به جای ساختن هر برنامه و توزیع جداگانه برنامه همانطور که ممکن است با Heroku، CloudFront، Google App Engine و غیره.

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

Kubernetes (همچنین به عنوان "K8s" شناخته می شود) یک سیستم ارکستراسیون کانتینر منبع باز برای خودکار کردن استقرار، مقیاس بندی و مدیریت برنامه های کاربردی کانتینری است. در ابتدا توسط گوگل توسعه داده شد و اکنون توسط بنیاد محاسبات بومی ابری (CNCF) نگهداری می شود. Kubernetes به سرعت تبدیل به استاندارد واقعی برای ارکستراسیون کانتینر شده است و توسط شرکت هایی مانند Uber، Dropbox و Salesforce برای مدیریت حجم کاری تولید خود استفاده می شود. در این مقاله، ما مقدمه ای از Kubernetes، از جمله ویژگی های کلیدی و نحوه عملکرد آن را ارائه خواهیم کرد.

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

Kubernetes چگونه کار می کند؟

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

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

در Kubernetes، کانتینرها در واحدهای منطقی به نام pods سازماندهی می شوند. یک pod گروهی از یک یا چند کانتینر است که با هم در یک گره مستقر شده اند و فضای نام شبکه یکسانی را به اشتراک می گذارند. Pods کوچکترین واحدهای قابل استقرار در Kubernetes هستند و برای میزبانی برنامه ها استفاده می شوند.

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

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

برخی از ویژگی های ارائه شده توسط Kubernetes عبارتند از:

· استقرار و مقیاس بندی برنامه های کاربردی کانتینری

· متعادل کننده بار و خود ترمیمی برنامه ها

· مدیریت پیکربندی و مدیریت مخفی

· تخصیص منابع و سهمیه بندی

· کشف سرویس و تعادل بار

Kubernetes اغلب همراه با فناوری‌های کانتینری‌سازی مانند Docker استفاده می‌شود و به‌عنوان راهی برای استقرار و مدیریت برنامه‌های مبتنی بر میکروسرویس‌ها به طور فزاینده‌ای محبوب می‌شود.

ابزار مدیریت لاگ ELK :

ELK Stack مجموعه‌ای از سه محصول منبع باز - Elasticsearch، Logstash و Kibana است. پشته ELK برای شناسایی مشکلات سرورها یا برنامه‌ها، ورود به سیستم متمرکز را فراهم می‌کند. این به شما امکان می دهد تمام سیاهههای مربوط را در یک مکان جستجو کنید. همچنین با اتصال گزارش‌ها در یک بازه زمانی خاص به یافتن مشکلات در چندین سرور کمک می‌کند.

· E مخفف ElasticSearch: برای ذخیره سیاههها استفاده می شود

· L مخفف LogStash است: برای حمل و نقل و همچنین پردازش و ذخیره گزارش استفاده می شود.

· K مخفف Kibana است: یک ابزار تجسم (واسط وب) است که از طریق Nginx یا Apache میزبانی می شود.

ElasticSearch، LogStash و Kibana همگی توسط شرکتی به نام Elastic توسعه، مدیریت و نگهداری می شوند.

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

ابزارهای مانیتورینگ مانند prometheus :

مستقیماً از منبع، "Prometheus یک جعبه ابزار نظارت و هشدار سیستم های منبع باز است..."

این بیانیه دقیق است اما واقعاً به مقیاسی که Prometheus به عنوان ابزار منبع باز واقعی برای جمع‌آوری معیارها و ایجاد هشدارهای اساسی در دنیای مبتنی بر ابر امروزی دست یافته است، نمی‌پردازد. این امر مخصوصاً اگر در جهان Kubernetes هستید که در آن یک واقعیت غیرقابل انکار است که Prometheus Data پادشاه است، صادق است.

معیارهای Prometheus از ذخیره‌گاه داده‌های خودش می‌آید که از آن برای جمع‌آوری داده‌های سری زمانی که از معیارهایی که نظارت می‌کند تولید می‌کند، استفاده می‌کند. Prometheus همچنین دارای مجموعه گسترده ای از پلاگین های موجود است که به آن امکان می دهد داده ها را در معرض راه حل های مختلف خارجی قرار دهد و داده ها را از هر تعداد منبع داده دیگر، از جمله چندین راه حل نظارت بر ابر عمومی، وارد کند. AWS حتی Prometheus را برای ارائه EKS (Kubernetes) خود از طریق سرویس CloudWatch خود توصیه می کند.

نظارت پرومتئوس محدودیت‌هایی دارد که در حول و حوش مدیریت داده‌ها و متریک با مقیاس‌پذیری رخ می‌دهد. برای مثال، اگر نیاز به کاهش مقیاس یک نمونه Kubernetes وجود داشته باشد، انتخاب‌های مربوط به نحوه مقیاس‌سازی تأثیر زیادی بر نحوه ذخیره داده‌های آن نمونه خواهد داشت. علاوه بر این، این امر می‌تواند جمع‌آوری این داده‌ها را برای بازگرداندن دیدگاهی جامع از نظارت Kubernetes دشوار کند. هنگامی که پیکربندی استاندارد به محدودیت های خود رسید، دو رویکرد اصلی وجود دارد. اینها باید یک سری از گره های کارگری داشته باشند که داده ها را برای مدیریت حجم تقسیم می کنند، یا Prometheus را برای داشتن چندین نمونه مستقل تقسیم می کنند. سناریوی بخش‌بندی‌شده به ابزار اضافی برای بازگرداندن آن دیدگاه جامع نیاز دارد. مانند فدرال‌سازی نمونه‌ها از طریق یک نمونه «جهانی»، که در آن راه‌حل‌های تجاری مانند Sumo Logic مقیاس‌پذیری را در پشت صحنه مدیریت می‌کنند.

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

Prometheus دارای قابلیت‌های تجسم اولیه است که می‌توان از آن‌ها استفاده کرد اگر بخواهید تعداد انگشت شماری از معیارها را برای مشاهده روندهای اساسی در معرض دید قرار دهید، اما تقریباً همه سازمان‌ها داده‌ها را در معرض مجموعه تجسم قدرتمندتری قرار می‌دهند.

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

تجزیه و تحلیل کد استاتیک :

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

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

· کد را بدون اجرای آن کد اسکن کنید

· آسیب پذیری های امنیتی را پس از اسکن لیست کنید

· کد را در برابر بهترین شیوه های صنعت اعتبار سنجی کنید

· توصیه هایی در مورد مکان و نحوه رفع مشکلات ارائه دهید

SonarQube ابزار پیشرو برای بازرسی مداوم کیفیت کد و امنیت کد و هدایت تیم های توسعه در طول بررسی کد است. SonarQube برای 27 زبان راهنمایی روشنی برای اصلاح ارائه می کند تا توسعه دهندگان بتوانند مشکلات را درک و برطرف کنند و بنابراین تیم ها می توانند نرم افزار بهتر و ایمن تری ارائه دهند. SonarQube در گردش کار شما ادغام می شود تا بازخورد مناسب را در زمان مناسب ارائه دهد: در IDE با SonarLint، در درخواست های کششی و در خود SonarQube. SonarQube با بیش از 225000 استقرار برای کمک به تیم‌های توسعه کوچک و سازمان‌های جهانی، ابزاری را برای تیم‌ها و شرکت‌ها در سراسر جهان فراهم می‌کند تا بر کیفیت کد و امنیت کد خود تأثیر بگذارند.

تحویل پیوسته :

تحویل مداوم فرآیند مهم ارائه نرم افزار/به روز رسانی ها به تولید در مراحل کوچکتر است، که اطمینان حاصل می کند که نرم افزار می تواند در هر زمان منتشر شود. با این رویکرد DevOps، تیم همیشه آماده «تحویل در هر زمان» به تولید خواهد بود.

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

تمرکز و هدف اصلی تحویل مداوم، ساخت، آزمایش و عرضه به مشتری بسیار سریعتر و بیشتر در چرخه های کوتاه است.

در زیر مزایای سی دی آورده شده است.

· تعداد تحویل را افزایش می دهد.

· خطر شکست در تولید را به حداقل می رساند.

· کار دستی را کاهش می دهد.

· اعتماد به نفس در تیم را افزایش می دهد.

· تیم را قادر می سازد تا همه چیز را خودکار کند.

· بازخورد سریعتر را فعال می کند.

SSO چیست :

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

سرویس مش :

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

این نوشته مربوط به بخشی از تمرینات معماری نرم افزار بهشتی می باشد.