خواندن ۱۰ دقیقه·۹ ماه پیش

معماری نرم افزار

اینجا قراره چند مفهوم پر کاربرد از معماری نرم افزار رو با هم مرور کنیم:

اولی Infrastructure as Code (IaC) : یه روش مدرن برای مدیریت زیرساخت‌ هاست. قبلا برای راه‌ اندازی یه سرور یا تنظیمات شبکه، باید دستی می ‌رفتیم تو پنل یا کانفیگ می ‌زدیم، حالا با کمک IaC این کار رو با کدنویسی انجام می ‌دیم؛ یعنی می ‌تونیم تنظیمات یه دیتابیس یا یه ماشین مجازی رو توی یه فایل کد بنویسیم و هر بار که خواستیم دقیقا همون زیرساخت ساخته بشه، همونو اجرا کنیم. خوبی ‌اش اینه که چون توی سیستم های کنترل نسخه مثل Git ذخیره می‌ شه، هر تغییری که بدیم قابل پیگیریه. اینطوری سرعت و دقت کار بالا می ‌ره و راحت ‌تر می‌ تونیم پروژه‌ هامونو گسترش بدیم. ابزارهای IaC می‌ فهمن چه چیزایی فرق کرده و فقط همونا رو تغییر می ‌دن که باعث می ‌شه سیستم همیشه منظم بمونه.

دومی API Gateway & Service Mesh : ارتباط بین سرویس ‌ها توی معماری میکروسرویس، از مهم‌ ترین چالش‌ هاست و برای مدیریتشون از API Gateway و Service Mesh استفاده می شه. API Gateway یه جور دروازه ورودی برای کل سیستم محسوب می ‌شه؛ یعنی هر درخواستی که از بیرون (کاربر یا کلاینت) میاد، اول از اینجا رد می ‌شه و این دروازه خودش می ‌دونه که هر درخواست باید به کدوم سرویس بره. می‌ تونه بررسی کنه کی اجازه دسترسی داره، اطلاعات رو کش کنه یا مسیردهی کنه. اما Service Mesh داخل سیستم کار می ‌کنه و روی ارتباط بین سرویس ‌ها تمرکز داره. رمزنگاری بین سرویس ‌ها، ردگیری و لاگ گرفتن و کنترل دقیق ترافیک شبکه داخلی رو هندل می ‌کنه. وقتی این دوتا با هم استفاده بشن، یه معماری قوی، امن و قابل گسترش داریم که هم از بیرون خوب مدیریت می ‌شه، هم توی خودش نظم داره.

سومی CQRS (Command Query Responsibility Segregation) : الگوی CQRS، یا همون جدا کردن مسئولیت‌ های خواندن و نوشتن، یه روش جالب برای طراحی سیستم‌ های پیچیده‌ ست. تو این روش، عملیات ‌هایی که اطلاعات رو تغییر میدن (ثبت سفارش یا ویرایش پروفایل) رو از عملیات‌ هایی که فقط اطلاعات رو نشون میدن (لیست سفارش‌ ها یا نمایش پروفایل) جدا می ‌کنیم؛ یعنی برای هرکدوم، یه مدل داده یا حتی یه دیتابیس جدا می‌ تونیم داشته باشیم. این کار چند تا مزیت داره: １. کارایی بهتر می ‌شه چون بخش خواندن رو میشه راحت ‌تر کش یا بهینه کرد. ２. اگر فقط بخش نمایش دچار مشکل بشه، رو منطق اصلی سیستم تأثیری نداره. ３. این جداسازی برای سیستم ‌های توزیع‌ شده مهمه چون کمک می‌ کنه راحت ‌تر مقیاس ‌پذیرشون کنیم و مدیریت ‌شون ساده‌ تر بشه.

چهارمی Event-Driven Architecture (EDA) : وقتی با میکروسرویس‌ ها سر و کار داریم، معماری مبتنی بر رویداد یه سبک طراحی کاربردیه. تو این معماری، همه چیز حول محور رویداد می‌ چرخه؛ مثلا وقتی یه سفارش ثبت می شه یا کاربر لاگین می ‌کنه، یه رویداد اتفاق افتاده. حالا این رویداد می ‌تونه به بقیه قسمت‌ های سیستم خبر بده که یه کاری انجام بدن، اونم بدون اینکه مستقیم بهشون بگه چیکار کنن! واسه این کار از message broker استفاده می‌ کنیم که نقش واسطه رو بین سرویس‌ های تولید کننده و مصرف ‌کننده بازی می ‌کنه. اینجوری سرویس ‌ها مستقل ‌تر و غیرهم ‌زمان کار می‌ کنن و سیستم هم راحت ‌تر مقیاس ‌پذیر می شه. از این معماری توی پردازش بلادرنگ، هماهنگ ‌سازی سرویس ‌ها یا ثبت دقیق اتفاقات سیستم استفاده می شه.

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

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

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

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

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

دهمی Low-code/No-code platforms : روش ‌های جدیدی برای توسعه نرم ‌افزار هستن که با استفاده از رابط‌ های کاربری بصری و کاهش نیاز به کدنویسی سنتی، این امکان رو می ‌دن که افراد مختلف، حتی کسانی که تجربه کدنویسی ندارن، بتونن اپلیکیشن بسازن. پلتفرم‌ های No-code برای کسانی که تخصص فنی ندارن، به‌ ویژه برای ساخت اپلیکیشن‌ های ساده مثل فرم‌ ها یا داشبوردها مناسب هستن، چون هیچ کدی نوشته نمی‌ شه. اما پلتفرم ‌های Low-code این امکان رو می ‌دن که با استفاده از کدنویسی اختیاری، بخش‌ های پیچیده ‌تر پروژه رو توسعه بدیم. این پلتفرم ‌ها معمولا برای توسعه‌ دهندگان حرفه‌ای کاربرد دارن و با امکانات سفارشی ‌سازی بیشتر و یکپارچگی با سرویس‌ های خارجی، برای پروژه‌ های بزرگتر مناسبن.

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

دوازدهمی Message Queue (such as Kafka and RabbitMQ) : صف‌ های پیام ابزارهایی هستن که امکان تبادل داده بین بخش ‌های مختلف سیستم رو به صورت غیرهمزمان فراهم می‌ کنن. این صف ‌ها فضای موقتی برای نگهداری پیام ‌ها ایجاد می‌ کنن و به این ترتیب اگر گیرنده در دسترس نباشه یا مشغول انجام کار دیگه ای باشه، پیام‌ ها از بین نمی ‌رن و به ترتیب مشخص باقی می‌ مونن. معمولا صف‌ های پیام به صورت FIFO عمل می‌ کنن. برنامه‌ ها پیام‌ هایی رو در صف قرار می‌ دن تا توسط برنامه‌ های دیگه در زمان مناسب پردازش بشن. این پیام‌ ها می ‌تونن شامل دستورات اجرایی، اعلان پایان یک فرآیند یا فقط اطلاعات ساده باشن. این مدل در معماری ‌هایی مثل میکروسرویس اهمیت زیادی داره، چون باعث جداسازی مؤلفه ‌ها و کاهش وابستگی زمانی می ‌شه و در نتیجه سیستم سریع‌ تر و قابل‌ اطمینان‌ تر می‌ شه.

سیزدهمی Container orchestration (such as Kubernetes) : کانتینرهای نرم ‌افزاری یه بسته‌ بندی سبک و قابل‌ حمل برای برنامه ‌ها هستن که باعث می ‌شن برنامه بدون وابستگی به سیستم‌ عامل یا تنظیمات خاص سرور، تو هر محیطی اجرا بشه. این ایده با ابزارهایی مثل Docker خیلی محبوب شد. حالا وقتی تعداد این کانتینرها توی پروژه زیاد می ‌شه، کنترلشون سخت می ‌شه. اینجاست که مفهوم ارکستراسیون کانتینر وارد می ‌شه. ارکستراسیون یعنی هماهنگ کردن و مدیریت خودکار کانتینرها؛ این که کِی اجرا بشن و چقدر منابع بگیرن تا اگه یکی خراب شد، سریع جایگزین بشه. ابزار معروفش Kubernetes هست که توسط گوگل ساخته شده و الان تقریبا استاندارد اصلی به حساب میاد. با این سیستم می ‌تونیم برنامه ‌ها رو توی مقیاس بزرگ، قابل ‌اعتماد و پایدار اجرا کنیم.

چهاردهمی Multi-Tenancy Architecture : معماری چند مستاجری به روشی در طراحی نرم ‌افزار گفته می ‌شه که در اون چندین مشتری (Tenant) به طور همزمان از یک نرم ‌افزار یا زیرساخت مشترک استفاده می ‌کنن، بدون اینکه به داده ‌های هم دیگه دسترسی داشته باشن. در این مدل، هر مشتری محیط کاربری و داده‌ های مخصوص به خودش رو داره، ولی همه بر روی یک نسخه از برنامه اجرا می ‌شن. این مدل به شرکت‌ ها کمک می ‌کنه تا هزینه‌ های زیرساختی رو کاهش بدن و به ‌روزرسانی ‌ها رو برای همه کاربران به‌ صورت یکپارچه مدیریت کنن. نکته مهم در این معماری، جداسازی داده‌ها (Data Isolation) هست که به حفظ امنیت و محرمانگی داده ‌ها کمک می ‌کنه.

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

منابع استفاده شده برای این مطالعه:

https://fa.wikipedia.org

https://7learn.com

https://sokanacademy.com

https://quera.org/blog

https://www.megaweb.ir

https://hamravesh.com

https://virgool.io

نرم افزارمعماری

زهرا گودآسیایی

شاید از این پست‌ها خوشتان بیاید

زهرا گودآسیایی

خواندن ۱۰ دقیقه·۹ ماه پیش

معماری نرم افزار

اینجا قراره چند مفهوم پر کاربرد از معماری نرم افزار رو با هم مرور کنیم:

اولی Infrastructure as Code (IaC) : یه روش مدرن برای مدیریت زیرساخت‌ هاست. قبلا برای راه‌ اندازی یه سرور یا تنظیمات شبکه، باید دستی می ‌رفتیم تو پنل یا کانفیگ می ‌زدیم، حالا با کمک IaC این کار رو با کدنویسی انجام می ‌دیم؛ یعنی می ‌تونیم تنظیمات یه دیتابیس یا یه ماشین مجازی رو توی یه فایل کد بنویسیم و هر بار که خواستیم دقیقا همون زیرساخت ساخته بشه، همونو اجرا کنیم. خوبی ‌اش اینه که چون توی سیستم های کنترل نسخه مثل Git ذخیره می‌ شه، هر تغییری که بدیم قابل پیگیریه. اینطوری سرعت و دقت کار بالا می ‌ره و راحت ‌تر می‌ تونیم پروژه‌ هامونو گسترش بدیم. ابزارهای IaC می‌ فهمن چه چیزایی فرق کرده و فقط همونا رو تغییر می ‌دن که باعث می ‌شه سیستم همیشه منظم بمونه.

دومی API Gateway & Service Mesh : ارتباط بین سرویس ‌ها توی معماری میکروسرویس، از مهم‌ ترین چالش‌ هاست و برای مدیریتشون از API Gateway و Service Mesh استفاده می شه. API Gateway یه جور دروازه ورودی برای کل سیستم محسوب می ‌شه؛ یعنی هر درخواستی که از بیرون (کاربر یا کلاینت) میاد، اول از اینجا رد می ‌شه و این دروازه خودش می ‌دونه که هر درخواست باید به کدوم سرویس بره. می‌ تونه بررسی کنه کی اجازه دسترسی داره، اطلاعات رو کش کنه یا مسیردهی کنه. اما Service Mesh داخل سیستم کار می ‌کنه و روی ارتباط بین سرویس ‌ها تمرکز داره. رمزنگاری بین سرویس ‌ها، ردگیری و لاگ گرفتن و کنترل دقیق ترافیک شبکه داخلی رو هندل می ‌کنه. وقتی این دوتا با هم استفاده بشن، یه معماری قوی، امن و قابل گسترش داریم که هم از بیرون خوب مدیریت می ‌شه، هم توی خودش نظم داره.

سومی CQRS (Command Query Responsibility Segregation) : الگوی CQRS، یا همون جدا کردن مسئولیت‌ های خواندن و نوشتن، یه روش جالب برای طراحی سیستم‌ های پیچیده‌ ست. تو این روش، عملیات ‌هایی که اطلاعات رو تغییر میدن (ثبت سفارش یا ویرایش پروفایل) رو از عملیات‌ هایی که فقط اطلاعات رو نشون میدن (لیست سفارش‌ ها یا نمایش پروفایل) جدا می ‌کنیم؛ یعنی برای هرکدوم، یه مدل داده یا حتی یه دیتابیس جدا می‌ تونیم داشته باشیم. این کار چند تا مزیت داره: １. کارایی بهتر می ‌شه چون بخش خواندن رو میشه راحت ‌تر کش یا بهینه کرد. ２. اگر فقط بخش نمایش دچار مشکل بشه، رو منطق اصلی سیستم تأثیری نداره. ３. این جداسازی برای سیستم ‌های توزیع‌ شده مهمه چون کمک می‌ کنه راحت ‌تر مقیاس ‌پذیرشون کنیم و مدیریت ‌شون ساده‌ تر بشه.

چهارمی Event-Driven Architecture (EDA) : وقتی با میکروسرویس‌ ها سر و کار داریم، معماری مبتنی بر رویداد یه سبک طراحی کاربردیه. تو این معماری، همه چیز حول محور رویداد می‌ چرخه؛ مثلا وقتی یه سفارش ثبت می شه یا کاربر لاگین می ‌کنه، یه رویداد اتفاق افتاده. حالا این رویداد می ‌تونه به بقیه قسمت‌ های سیستم خبر بده که یه کاری انجام بدن، اونم بدون اینکه مستقیم بهشون بگه چیکار کنن! واسه این کار از message broker استفاده می‌ کنیم که نقش واسطه رو بین سرویس‌ های تولید کننده و مصرف ‌کننده بازی می ‌کنه. اینجوری سرویس ‌ها مستقل ‌تر و غیرهم ‌زمان کار می‌ کنن و سیستم هم راحت ‌تر مقیاس ‌پذیر می شه. از این معماری توی پردازش بلادرنگ، هماهنگ ‌سازی سرویس ‌ها یا ثبت دقیق اتفاقات سیستم استفاده می شه.

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

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

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

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

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

دهمی Low-code/No-code platforms : روش ‌های جدیدی برای توسعه نرم ‌افزار هستن که با استفاده از رابط‌ های کاربری بصری و کاهش نیاز به کدنویسی سنتی، این امکان رو می ‌دن که افراد مختلف، حتی کسانی که تجربه کدنویسی ندارن، بتونن اپلیکیشن بسازن. پلتفرم‌ های No-code برای کسانی که تخصص فنی ندارن، به‌ ویژه برای ساخت اپلیکیشن‌ های ساده مثل فرم‌ ها یا داشبوردها مناسب هستن، چون هیچ کدی نوشته نمی‌ شه. اما پلتفرم ‌های Low-code این امکان رو می ‌دن که با استفاده از کدنویسی اختیاری، بخش‌ های پیچیده ‌تر پروژه رو توسعه بدیم. این پلتفرم ‌ها معمولا برای توسعه‌ دهندگان حرفه‌ای کاربرد دارن و با امکانات سفارشی ‌سازی بیشتر و یکپارچگی با سرویس‌ های خارجی، برای پروژه‌ های بزرگتر مناسبن.

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

دوازدهمی Message Queue (such as Kafka and RabbitMQ) : صف‌ های پیام ابزارهایی هستن که امکان تبادل داده بین بخش ‌های مختلف سیستم رو به صورت غیرهمزمان فراهم می‌ کنن. این صف ‌ها فضای موقتی برای نگهداری پیام ‌ها ایجاد می‌ کنن و به این ترتیب اگر گیرنده در دسترس نباشه یا مشغول انجام کار دیگه ای باشه، پیام‌ ها از بین نمی ‌رن و به ترتیب مشخص باقی می‌ مونن. معمولا صف‌ های پیام به صورت FIFO عمل می‌ کنن. برنامه‌ ها پیام‌ هایی رو در صف قرار می‌ دن تا توسط برنامه‌ های دیگه در زمان مناسب پردازش بشن. این پیام‌ ها می ‌تونن شامل دستورات اجرایی، اعلان پایان یک فرآیند یا فقط اطلاعات ساده باشن. این مدل در معماری ‌هایی مثل میکروسرویس اهمیت زیادی داره، چون باعث جداسازی مؤلفه ‌ها و کاهش وابستگی زمانی می ‌شه و در نتیجه سیستم سریع‌ تر و قابل‌ اطمینان‌ تر می‌ شه.

سیزدهمی Container orchestration (such as Kubernetes) : کانتینرهای نرم ‌افزاری یه بسته‌ بندی سبک و قابل‌ حمل برای برنامه ‌ها هستن که باعث می ‌شن برنامه بدون وابستگی به سیستم‌ عامل یا تنظیمات خاص سرور، تو هر محیطی اجرا بشه. این ایده با ابزارهایی مثل Docker خیلی محبوب شد. حالا وقتی تعداد این کانتینرها توی پروژه زیاد می ‌شه، کنترلشون سخت می ‌شه. اینجاست که مفهوم ارکستراسیون کانتینر وارد می ‌شه. ارکستراسیون یعنی هماهنگ کردن و مدیریت خودکار کانتینرها؛ این که کِی اجرا بشن و چقدر منابع بگیرن تا اگه یکی خراب شد، سریع جایگزین بشه. ابزار معروفش Kubernetes هست که توسط گوگل ساخته شده و الان تقریبا استاندارد اصلی به حساب میاد. با این سیستم می ‌تونیم برنامه ‌ها رو توی مقیاس بزرگ، قابل ‌اعتماد و پایدار اجرا کنیم.

چهاردهمی Multi-Tenancy Architecture : معماری چند مستاجری به روشی در طراحی نرم ‌افزار گفته می ‌شه که در اون چندین مشتری (Tenant) به طور همزمان از یک نرم ‌افزار یا زیرساخت مشترک استفاده می ‌کنن، بدون اینکه به داده ‌های هم دیگه دسترسی داشته باشن. در این مدل، هر مشتری محیط کاربری و داده‌ های مخصوص به خودش رو داره، ولی همه بر روی یک نسخه از برنامه اجرا می ‌شن. این مدل به شرکت‌ ها کمک می ‌کنه تا هزینه‌ های زیرساختی رو کاهش بدن و به ‌روزرسانی ‌ها رو برای همه کاربران به‌ صورت یکپارچه مدیریت کنن. نکته مهم در این معماری، جداسازی داده‌ها (Data Isolation) هست که به حفظ امنیت و محرمانگی داده ‌ها کمک می ‌کنه.

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

منابع استفاده شده برای این مطالعه:

https://fa.wikipedia.org

https://7learn.com

https://sokanacademy.com

https://quera.org/blog

https://www.megaweb.ir

https://hamravesh.com

https://virgool.io

نرم افزارمعماری

زهرا گودآسیایی

شاید از این پست‌ها خوشتان بیاید