https://virgool.io/feed/@hasanroknabady fa 2026-04-15 07:00:54 https://files.virgool.io/upload/users/3526545/avatar/avatar.png?height=120&width=120 https://virgool.io/@hasanroknabady https://virgool.io/@hasanroknabady/%DA%AF%D8%B2%D8%A7%D8%B1%D8%B4%DB%8C-%D8%A7%D8%B2-%D8%A7%D9%87%D9%85%DB%8C%D8%AA-%D9%88-%D8%B3%D8%A7%D8%AE%D8%AA%D8%A7%D8%B1-%D8%B3%D9%86%D8%AF-%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-sad-%D9%88-%D9%86%DA%AF%D8%A7%D9%87%DB%8C-%DA%A9%D9%88%D8%AA%D8%A7%D9%87-%D8%A8%D9%87-%D9%85%D8%AF%D9%84-c4-ofah2be03ehb مقدمه این گزارش در مورد سند معماری و ویژگی ها و موارد مطرح شده در آن بعد از اینکه به صحبت‌های استاد، دکتر علی اکبری، در مورد سند معماری نرم‌افزار ([1]SAD) گوش دادم و ویدیوی آقای سایمون براون در مورد مدل C4 را دیدم، و همچنین اسلایدها و سایت c4model.com را بررسی کردم، نوشته شده است.همچنین این محتوا در پست لینکدین هم در لینک زیر قابل مشاهده است:لینک پست لینکدین : https://www.linkedin.com/posts/hasan-roknabadi-663854303_%DA%AF%D8%B2%D8%A7%D8%B1%D8%B4%DB%8C-%D8%A7%D8%B2-%D8%A7%D9%87%D9%85%DB%8C%D8%AA-%D9%88-%D8%B3%D8%A7%D8%AE%D8%AA%D8%A7%D8%B1-%D8%B3%D9%86%D8%AF-%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-activity-7331695411457429505-V58l?utm_source=share&utm_medium=member_desktop&rcm=ACoAAE2Lw6sBPbQg4zjjJqpOgk15lYbqrZpCkxU چرا سند معماری نرم‌افزار (SAD) اینقدر مهم است؟ SAD مثل یک نقشه راه اصلی برای پروژه است . یعنی به تیم کمک می‌کند که بدانند دارند چه کار می‌کنند و تصمیم‌های بعدی بر اساس آن گرفته می‌شود. دلایل اهمیتش را می‌توانم اینطور بگویم:همه با هم یک چیز را بفهمند: همانطور که در اسلاید ۶ میبینیم، SAD کمک می‌کند تا معمار، تیم فنی (طراح‌ها و برنامه‌نویس‌ها)، مدیرها، کارفرما و بقیه افرادی که در پروژه نقش دارند (چه فنی باشند چه نباشند)، یک درک مشترک از معماری داشته باشند.تصمیم‌های مهم فراموش نشوند: در معماری کلی تصمیم فنی مهم گرفته می‌شود. SAD این تصمیم‌ها و اینکه چرا گرفته شده‌اند (مثلاً چرا از فلان تکنولوژی استفاده کردیم) را ثبت می‌کند. این موضوع مخصوصاً در پروژه‌های بزرگ یا وقتی اعضای تیم عوض می‌شوند، خیلی به درد می‌خورد.دانش معماری گم نشود: خیلی وقت‌ها دانش معماری فقط توی ذهن معمار یا چند نفر از بچه‌های تیم است. SAD کمک می‌کند این دانش که شاید "پراکنده و ناقص" باشد، به صورت "واضح و کامل" نوشته شود .ریسک کمتر و وابستگی کمتر به یک نفر: یکی از بهترین فایده‌هایش که در اسلاید ۸ با عنوان "Bus Factor" گفته شده، این است که دیگر پروژه خیلی به یک نفر خاص وابسته نمی‌شود. اگر فقط یک نفر معماری را بلد باشد و از تیم برود، پروژه به مشکل می‌خورد.راهنمای تیم و آموزش نیروهای جدید: SAD به تیم فنی کمک می‌کند ساختار کلی سیستم را بفهمند و کارشان را بهتر انجام دهند. برای آموزش نیروهای جدید هم خیلی خوب است .راحت‌تر می‌شود معماری را بررسی کرد و مشورت گرفت: وقتی یک سند منظم داشته باشیم، راحت‌تر می‌توانیم معماری را ارزیابی کنیم یا از متخصص‌های دیگر مشورت بگیریم.با روش‌های چابک هم جور درمی‌آید: شاید فکر کنیم مستندسازی با چابکی مخالف است، اما اسلایدهای ۱۰ و ۱۲ خوب توضیح می‌دهند که منظور از چابکی، این نیست که اصلاً مستند نداشته باشیم، بلکه باید "فقط به اندازه لازم و مفید" مستند درست کنیم (Just Enough). یک SAD خوب حتی می‌تواند به چابک بودن پروژه کمک کند، البته به شرطی که خودش هم سریع و راحت تهیه و آپدیت شود.سند معماری نرم‌افزار (SAD) باید شامل چه چیزهایی باشد؟ بر اساس اسلایدها ، یک SAD خوب معمولاً دو قسمت اصلی دارد: "فضای مسئله" و "فضای راه‌حل" .الف) فضای مسئله[2]: هدف این بخش این است که دقیقاً بگوییم نرم‌افزار قرار است چه مشکلی را حل کند. 1. مقدمه : یک توضیح کوتاه در مورد نرم‌افزار، اینکه پروژه دقیقاً شامل چه چیزهایی می‌شود و چه چیزهایی نمی‌شود. 2.نمای موارد کاربرد[3] : مشخص کردن اینکه چه کسانی (Actors) از سیستم استفاده می‌کنند و کارهای اصلی که سیستم باید انجام دهد چه هستند. این بخش به ما می‌گوید سیستم چه کارهایی باید بتواند انجام دهد. 3. ویژگی‌های کیفی[4]: مشخص کردن ویژگی‌های مهم غیرکارکردی سیستم مثل سرعت ، همیشه در دسترس بودن ، امنیت ، راحت بودن تغییرات بعدی و غیره. مهم است که این ویژگی‌ها را بشود اندازه گرفت و برای هر کدام مثال‌هایی (سناریو) تعریف کنیم . (این بخش به طور کامل در کلاس نیز تدریس شده است و بیشتر از این به آن نمیپردازیم)ب) فضای راه‌حل[5]: این بخش توضیح می‌دهد که معماری چطور مشکل را حل می‌کند و ویژگی‌های کیفی را برآورده می‌کند. چند نمای مختلف در این بخش داریم: 1. نمای منطقی - [6]: توضیح بخش‌های اصلی معماری (Building Blocks)، زیرسیستم‌ها، سرویس‌ها و اینکه چطور با هم کار می‌کنند، البته در یک سطح کلی و مفهومی. 2. نمای استقرار [7] - : اینکه نرم‌افزار چطور روی سخت‌افزار و سرورها نصب و اجرا می‌شود . 3. نمای پردازه[8] - : توضیح برنامه‌های در حال اجرا، و اینکه چطور با هم ارتباط برقرار می‌کنند و چه اتفاق‌هایی در زمان اجرای نرم‌افزار می‌افتد (مثلاً مدیریت همزمانی کارها). 4. نمای توسعه و پیاده‌سازی[9] - : ساختار پروژه از نگاه برنامه‌نویس‌ها، یعنی ماژول‌ها، پکیج‌ها و لایه‌های مختلف کد.5. بخش‌ها و نماهای مهم دیگر (اسلایدهای ۷۳ به بعد):نمای پویا[10]: نشان می‌دهد که بخش‌های مختلف سیستم چطور با هم کار می‌کنند تا یک کار خاص (مثلاً یک مورد کاربرد مهم) انجام شود. معمولاً با نمودارهای توالی نشان داده می‌شود.نمای تست، لاگ و پایش (Test, Log, Monitoring Views): روش‌ها و ابزارهایی که برای تست نرم‌افزار، ثبت اتفاقات (لاگ‌ها) و بررسی وضعیت سیستم استفاده می‌شود.نمای داده[11]: تصمیم‌هایی که در مورد پایگاه داده، مدیریت داده‌ها و الگوهای مربوط به آن گرفته شده و الگوها و تکنیک‌هایی که استفاده شده است.تصمیم‌های مهم معماری[12]: (این بخش در فیلم تدریسی استاد وجود ندارد و در اسلاید های جدید است.) این بخش که در اسلایدهای ۲۷-۳۰ به آن اشاره شده، برای اینکه بدانیم "چرا" یک تصمیم خاص گرفته شده، خیلی مهم است برای دانستن ریسک‌ها و بدهی‌های فنی (چیزهایی که می‌دانیم مشکل دارند ولی فعلاً حل نشده‌اند) و مسائل مربوط به امنیت و گزارش‌گیری.مدل C4: یک روش کاربردی برای نشان دادن معماریشکل : مدل C4 آقای سایمون براون در ویدیوی خود و اسلایدهای ۱۶ تا ۲۵ استاد، مدل C4 که یک روش ساده و مرحله به مرحله را معرفی کردند که برای نشان دادن معماری نرم‌افزار در چهار سطح مختلف است. این مدل کمک می‌کند تا معماری را راحت‌تر بفهمیم و به بقیه هم نشان دهیم و با همان اصل "فقط به اندازه لازم" هم جور در می‌آید.سطح ۱: نمودار زمینه[13] : کلی‌ترین سطح که سیستم نرم‌افزاری ما را مثل یک جعبه سیاه نشان می‌دهد و می‌گوید با چه کسانی و چه سیستم‌های دیگری در ارتباط است. این نمودار را همه، حتی کسانی که فنی نیستند، می‌فهمند.سطح ۲: نمودار کانتینر[14] : اگر روی آن جعبه سیاه زوم کنیم، بخش‌های اصلی قابل اجرا یا قابل نصب (کانتینرها) را می‌بینیم. کانتینر می‌تواند یک برنامه وب، یک اپ موبایل، یک پایگاه داده و غیره باشد. اینکه این کانتینرها چطور با هم حرف می‌زنند و از چه تکنولوژی‌هایی استفاده می‌کنند هم در این سطح معلوم می‌شود.سطح ۳: نمودار کامپوننت[15]: هر کانتینر را می‌توانیم به بخش‌های کوچکتری به اسم کامپوننت تقسیم کنیم. کامپوننت‌ها مجموعه‌ای از کارهای مرتبط هستند و معمولاً در کد به صورت ماژول یا پکیج دیده می‌شوندمثلاً یک کنترلر در معماری[16] .سطح ۴: نمودار کد : جزئی‌ترین سطح که ساختار کد مثل کلاس‌ها و ارتباط بین آن‌ها را نشان می‌دهد. همانطور که گفته شد، معمولاً این سطح را دستی در SAD نمی‌نویسیم و ابزارهایی مثل IDEها می‌توانند آن را تولید کنند.نکته‌های مهم در مورد C4:ابزارهایی مثل Structurizr وجود دارند(که سایمون برایون آن را دولوپ کرده است!!) که کمک می‌کنند این نمودارها را با نوشتن متن (DSL) درست کنیم. اینطوری نگهداری و آپدیت کردنشان کنار کد خیلی راحت‌تر می‌شود.(سایمون برایون در اخر ویدیو اشاره میکند که اصلا از ابزارهایی مثل ویزیو استفاده نکنید زیرا برای معماری نرم افزار طراحی نشده است.)مدل C4 می‌تواند برای نشان دادن چیزهای دیگری مثل نحوه استقرار یا چگونگی کارکرد سیستم در یک سناریوی خاص هم استفاده شود.حرف آخر و چند توصیه از طرف من: با دیدن این ویدیوها و خواندن اسلایدها، به این نتیجه رسیدم که:سند معماری یک چیز ثابت نیست و باید در طول پروژه آپدیت شود .نباید خودمان را درگیر جزئیات خیلی ریز و بی‌اهمیت کنیم . باید روی تصمیم‌های بزرگ و تاثیرگذار تمرکز کنیم.بهتر است از یک قالب مشخص برای SAD استفاده کنیم (حتی اگر لازم شد تغییرش بدهیم) تا همه چیز یکدست و قابل فهم باشد .مدل C4 یک راه خیلی خوب برای کشیدن نمودارهایی است که همه بفهمند و در سطوح مختلف جزئیات را نشان می‌دهد.نوشتن اینکه "چرا" یک تصمیم معماری گرفته شده (ADRs) به اندازه خود معماری مهم است.مسئول نوشتن و نگهداری SAD باید یک نفر باتجربه و فنی در تیم باشد .[1] Software Architecture Document[2] Problem Space[3] Use Case View[4] Quality Attributes[5] Solution Space[6] Logical View[7] Deployment/Physical View[8] Process View[9] Development/Implementation View[10] Dynamic View / Use Case Realization[11] Data View[12] Architecture Decision Records - ADRs[13] System Context Diagram[14] Container Diagram[15] Component Diagram[16] MVC حسن رکن آبادی حسن رکن آبادی Fri, 23 May 2025 18:17:31 +0330 https://virgool.io/@hasanroknabady/%DB%B1%DB%B5-%D9%85%D9%81%D9%87%D9%88%D9%85-%D9%85%D9%87%D9%85-%D8%AF%D8%B1-%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-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-%D9%88-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF%DB%8C-tr64xbtyo9s0 سلام به همه دوستان و همکاراندر حال حاضر چندین موضوع بروز و جدید رو مطالعه کردم و دیدم بد نیست اون هارو به زبان ساده اما کاربردی و فنی بیان کنم. اخیراً درگیر تمرینی در درس معماری نرم‌افزار بودم که هدفش آشنایی اولیه با چندتا از این مفاهیم داغ بود. گفتم شاید بد نباشه خلاصه‌ای از برداشت‌های خودم رو با شما هم به اشتراک بذارم. این توضیحات سعی شده خیلی ساده و روان باشه، جوری که انگار داریم با هم گپ می‌زنیم. پس اگه شما هم مثل من دنبال یه دید کلی و سریع به این موضوعات هستید، همراهم باشید!همچنین لینک پست لیندکدین در زیر قابل مشاهده است: https://www.linkedin.com/posts/hasan-roknabadi-663854303_%DB%B1%DB%B5-%D9%85%D9%81%D9%87%D9%88%D9%85-%D9%85%D9%87%D9%85-%D8%AF%D8%B1-%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-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-activity-7327314787665629184-rOTi?utm_source=share&utm_medium=member_desktop&rcm=ACoAAE2Lw6sBPbQg4zjjJqpOgk15lYbqrZpCkxU۱. زیرساخت به عنوان کد (Infrastructure as Code - IaC)تا حالا شده بخواهید یک زیرساخت پیچیده رو بارها و بارها با تنظیمات یکسان راه‌اندازی کنید؟ مثلاً چند سرور، شبکه، دیتابیس و کلی تنظیمات دیگه. انجام دستی این کار هم زمان‌بره، هم مستعد خطا.اینجا «زیرساخت به عنوان کد» یا IaC به کمک میاد IaC .یعنی به جای اینکه دستی تو کنسول AWS یا Azure کلیک کنیم و منابع بسازیم، میایم با استفاده از کدهایی (مثلاً با ابزارهایی مثل Terraform یا CloudFormation) تعریف می‌کنیم که چه زیرساختی با چه مشخصاتی می‌خوایم. این کدها مثل دستور غذایی یا اسکریپت کارا که در ابزار های زیر ساخت به عنوان کد نام برده شد استفاده میشوند و فقط یک بار می‌نویسیمشون و بعد هر چند بار که بخوایم، می‌تونیم همون زیرساخت رو بدون کم و کاست و دقیقاً مث دفعه اول بسازیم. مزیت بزرگش اینه که زیرساختمون هم مثل کدهای برنامه‌مون قابل ورژن‌کنترل، بازبینی و اتوماتیک‌سازی میشه. دیگه خبری از "روی سیستم من کار می‌کرد!" برای زیرساخت نیست، چون همه چیز مستند و قابل تکراره.۲. درگاه API و شبکه خدماتی (API Gateway & Service Mesh)وقتی با معماری میکروسرویس کار می‌کنیم، تعداد زیادی سرویس کوچیک داریم که با هم حرف می‌زنن. اینجا دو تا مفهوم مهم مطرح میشه:فکر کنید یه ساختمون بزرگ با کلی دفتر (میکروسرویس) دارید.در واقع API Gateway مثل نگهبان یا مسئول پذیرش دم در اون ساختمونه. تمام درخواست‌های خارجی (مثلاً از اپ موبایل یا وب) اول به API Gateway می‌رسه. اون هم کارایی مثل احراز هویت، محدود کردن تعداد درخواست‌ها (Rate Limiting)، مسیریابی درخواست به سرویس مربوطه و حتی گاهی تبدیل فرمت درخواست‌ها رو انجام میده. اینطوری هم کلاینت‌ها راحت‌ترن (یه نقطه ورود دارن) و هم سرویس‌های داخلی از خیلی پیچیدگی‌ها خلاص میشن.حالا اگه بخوایم ارتباطات داخل همون ساختمون، یعنی بین خود دفترها (میکروسرویس‌ها) رو مدیریت کنیم چی؟ Service Mesh مثل یه سیستم مخابراتی پیشرفته داخلی برای اون ساختمونه. این ابزار به ما کمک می‌کنه تا ترافیک بین سرویس‌ها رو مدیریت کنیم، امنیت ارتباطاتشون رو برقرار کنیم، ببینیم کدوم سرویس‌ها با هم حرف می‌زنن و اگه مشکلی پیش اومد سریع‌تر پیداش کنیم. ابزارهایی مثلIstio یاLinkerd این کار رو انجام میدن. حال Service Mesh روی ارتباطات سرویس به سرویس تمرکز داره، در حالی که API Gateway بیشتر روی ارتباط کلاینت-به-سرویس.به طور کلی فرق بین این دو را میتوان این گونه بیان کرد که در Service Mesh هدف اصلی ارتباط بین خود سرویس ها و در API Gateway ارتباط بین کلاینت و سرویس ها مدنظر و هدف اصلی است.۳.مفهوم CQRS – (Command Query Responsibility Segregation)تصور کنید یه سیستم دارید که همزمان هم باید داده‌های زیادی رو بخونه (مثلاً نمایش لیست محصولات) و هم داده‌های جدیدی رو بنویسه یا ویرایش کنه (مثلاً ثبت سفارش جدید). گاهی اوقات، مدل داده‌ای که برای نوشتن اطلاعات مناسبه، برای خوندن بهینه نیست (و برعکس) CQRS میگه بیایم این دو تا کار رو از هم جدا کنیم. یعنی یه مدل جدا برای "دستورها" (Commands) که مسئول تغییر دادن داده‌ها هستن (مثل ایجاد، ویرایش، حذف) و یه مدل جدا برای "پرس‌وجوها" (Queries) که فقط مسئول خوندن داده‌ها هستن. اینطوری می‌تونیم هر بخش رو متناسب با نیازش بهینه کنیم. مثلاً دیتابیسی که برای نوشتن سریع طراحی شده رو برای دستورها استفاده کنیم و دیتابیسی که برای خوندن سریع بهینه شده رو برای پرس‌وجوها. این کار باعث میشه سیستم‌مون انعطاف‌پذیرتر و مقیاس‌پذیرتر بشه.۴. معماری رویداد محور (Event-Driven Architecture - EDA)در معماری رویداد محور، ارتباط بین اجزای مختلف سیستم (مثلاً میکروسرویس‌ها) بر اساس "رویدادها" (Events) شکل می‌گیره. رویداد یعنی یه اتفاق مهمی که تو سیستم افتاده، مثلاً "سفارش جدید ثبت شد" یا "کاربر لاگین کرد". وقتی یه سرویس کاری انجام میده که منجر به یه رویداد میشه، اون رویداد رو منتشر می‌کنه (مثلاً تو یه Message Queue می‌ذاره). بقیه سرویس‌هایی که به اون نوع رویداد علاقه‌مند هستن، بهش گوش میدن و کار خودشون رو انجام میدن. مثلاً وقتی رویداد "سفارش جدید ثبت شد" منتشر میشه، سرویس انبارداری می‌فهمه که باید موجودی رو کم کنه و سرویس ارسال ایمیل هم یه ایمیل تایید برای مشتری می‌فرسته. مزیت بزرگش اینه که سرویس‌ها از هم مستقل (decoupled) میشن و نیازی نیست مستقیم همدیگه رو صدا بزنن. این باعث میشه سیستم انعطاف‌پذیرتر، مقیاس‌پذیرتر و مقاوم‌تر در برابر خطا بشه.۵. معماری بدون سرور (Serverless Architecture)اسم "بدون سرور" شاید یکم گمراه‌کننده باشه، چون بالاخره یه جایی سروری هست که کد ما رو اجرا می‌کنه! اما نکته اینجاست که مادیگه درگیر مدیریت اون سرورها (نصب سیستم‌عامل، پچ‌های امنیتی، مقیاس‌پذیری و ...) نیستیم. در معماری Serverless، ما کدهامون رو به صورت "توابع" (Functions) می‌نویسیم و اون‌ها رو روی پلتفرم‌های ابری مثل AWS Lambda یا Azure Functions بارگذاری می‌کنیم. این توابع فقط وقتی اجرا میشن که یه اتفاقی (event) بیفته، مثلاً یه درخواست HTTP بیاد یا یه فایل تو فضای ذخیره‌سازی آپلود بشه. ما هم فقط به اندازه زمانی که کدمون اجرا شده و منابعی که مصرف کرده پول میدیم. این یعنی صرفه‌جویی خیلی خوب در هزینه‌ها، مخصوصاً برای اپلیکیشن‌هایی که همیشه ترافیک بالایی ندارن. مقیاس‌پذیری هم به صورت خودکار توسط پلتفرم انجام میشه.۶. روش API (API-first Approach)در این رویکرد، قبل از اینکه حتی یه خط کد برای رابط کاربری (UI) وب یا موبایل بنویسیم، اول میریم سراغ طراحی و ساخت APIها. API مثل یه قرارداد یا رابط استاندارد بین بخش‌های مختلف نرم‌افزار یا حتی بین نرم‌افزار ما و دنیای بیرون عمل می‌کنه. وقتی اول API رو طراحی می‌کنیم، تیم‌های مختلف (مثلاً تیم بک‌اند، تیم فرانت‌اند، تیم موبایل) می‌تونن به صورت موازی و مستقل از هم کار کنن، چون می‌دونن قراره با چه API هایی صحبت کنن. این کار باعث میشه توسعه سریع‌تر بشه، مستندسازیAPIها جدی‌تر گرفته بشه و در نهایت، تجربه کاربری یکپارچه‌تری روی پلتفرم‌های مختلف داشته باشیم. انگار اول نقشه راه و اتصالات اصلی رو مشخص می‌کنیم، بعد میریم سراغ ساخت ساختمون‌ها.۷.مفهوم (Domain Driven Design) DDDطراحی دامنه محور یا DDD یه رویکرد برای ساخت نرم‌افزارهای پیچیده‌ست که تمرکزش روی درک عمیق "دامنه کسب‌وکار" (Business Domain) و مدل‌سازی اون در نرم‌افزاره. ایده اصلی اینه که نرم‌افزار باید بازتابی از واقعیت‌های کسب‌وکار باشه. برای همین، خیلی مهمه که توسعه‌دهنده‌ها و کارشناس‌های اون کسب‌وکار(Domain Experts) یه زبان مشترک (Ubiquitous Language) داشته باشن و از همون اصطلاحات در کد و مستندات استفاده کنن. DDD مفاهیمی مثل (Bounded Context) مرزبندی بخش‌های مختلف دامنه (Aggregate) مجموعه‌ای از اشیاء که با هم یک واحد رو تشکیل میدن Entity و Value Object رو معرفی می‌کنه تا به ما کمک کنه مدل‌های دقیق‌تر و قابل فهم‌تری از کسب‌وکار بسازیم. این کار در نهایت به تولید نرم‌افزاری منجر میشه که نگهداریش راحت‌تره و بهتر با نیازهای واقعی کسب‌وکار هماهنگه.۸. معماری شش ضلعی (Hexagonal Architecture / Ports and Adapters)معماری شش ضلعی (که بهش "پورت‌ها و آداپتورها" هم میگن) یه الگو برای طراحی نرم‌افزاره که هدفش جداسازی کامل منطق اصلی برنامه هسته یا Domain Logic از نگرانی‌های بیرونی مثل رابط کاربری، دیتابیس، یا سرویس‌های جانبیه. تصور کنید هسته برنامه شما در مرکز قرار داره. این هسته از طریق "پورت‌ها" (که معمولاً اینترفیس‌هایی در کد هستن) با دنیای بیرون ارتباط برقرار می‌کنه. برای هر تکنولوژی یا ابزار خارجی (مثل یه دیتابیس خاص یا یه فریمورک وب) یه "آداپتور" نوشته میشه که اون پورت رو پیاده‌سازی می‌کنه. مثلاً یه آداپتور برای دیتابیس MySQL و یه آداپتور دیگه برای PostgreSQL اینطوری اگه بخوایم دیتابیس رو عوض کنیم، فقط کافیه آداپتورش رو عوض کنیم و هسته برنامه دست نخورده باقی می‌مونه. این معماری تست‌پذیری و انعطاف‌پذیری سیستم رو خیلی بالا می‌بره.۹. منبع‌یابی رویداد (Event Sourcing)در روش سنتی، ما معمولاً "وضعیت فعلی" داده‌ها رو تو دیتابیس ذخیره می‌کنیم. مثلاً اگه موجودی حساب کاربری تغییر کنه، فقط مقدار جدید موجودی رو آپدیت می‌کنیم. اما در Event Sourcing، ما تمام "تغییرات" رو به صورت دنباله‌ای از "رویدادها" ذخیره می‌کنیم. یعنی به جای اینکه بگیم "موجودی فعلی ۱۰۰۰ تومان است"، میگیم "ابتدا ۵۰۰ تومان واریز شد، سپس ۲۰۰ تومان برداشت شد، سپس ۷۰۰ تومان واریز شد". وضعیت فعلی سیستم با اجرای دوباره این رویدادها از ابتدا به دست میاد. این کار مزایای زیادی داره: هیچ داده‌ای از بین نمیره و همیشه می‌تونیم تاریخچه کامل تغییرات رو ببینیم (عالی برای Audit) ، می‌تونیم وضعیت سیستم رو در هر نقطه‌ای از زمان بازسازی کنیم، و حتی می‌تونیم مدل‌های مختلفی برای خوندن داده‌ها(Read Models) بر اساس همین رویدادها بسازیم که به CQRS خیلی کمک می‌کنه. مثل دفتر کل حسابداری میمونه که همه تراکنش‌ها رو ثبت می‌کنه.۱۰.پلتفرم های (Low-code/No-code Platforms)این پلتفرم‌ها به افراد این امکان رو میدن که اپلیکیشن‌های نرم‌افزاری رو با حداقل کدنویسی (Low-code) یا حتی بدون هیچ کدنویسی(No-code) بسازن. معمولاً این کار از طریق رابط‌های کاربری گرافیکی، ابزارهای کشیدن و رها کردن(Drag-and-drop) و قالب‌های از پیش آماده انجام میشه. هدف اصلی اینه که توسعه نرم‌افزار سریع‌تر بشه و حتی افرادی که تخصص برنامه‌نویسی ندارن (مثل تحلیل‌گران کسب‌وکار یا مدیران محصول) هم بتونن ایده‌هاشون رو به سرعت پیاده‌سازی کنن. این پلتفرم‌ها برای ساخت پروتوتایپ‌ها، اپلیکیشن‌های داخلی ساده، یا اتوماسیون فرآیندهای کسب‌وکار خیلی مفید هستن. البته برای سیستم‌های خیلی پیچیده و با نیازمندی‌های خاص، ممکنه محدودیت‌هایی داشته باشن، اما سرعت و سادگی‌شون واقعاً جذابه.۱۱. سیستم‌های مدیریت فرآیندهای کسب‌وکار (BPMS - Business Process Management Systems)هر سازمانی برای انجام کارهاش یه سری فرآیند داره، مثل فرآیند استخدام، فرآیند تایید مرخصی، یا فرآیند پردازش سفارش مشتریBPMS .نرم‌افزاریه که به سازمان‌ها کمک می‌کنه این فرآیندها رو به صورت دیجیتالی مدل‌سازی، اجرا، پایش و بهینه‌سازی کنن. با BPMS می‌تونیم نمودار جریان کار(Workflow) هر فرآیند رو بکشیم، مشخص کنیم هر مرحله توسط چه کسی و با چه شرایطی انجام بشه، فرم‌های لازم رو طراحی کنیم و کل فرآیند رو اتوماتیک کنیم. این کار باعث میشه فرآیندها شفاف‌تر، کارآمدتر و با خطای کمتری انجام بشن. همچنین BPMS امکان مانیتورینگ و گزارش‌گیری از عملکرد فرآیندها رو میده تا نقاط قابل بهبود رو شناسایی کنیم. در واقع BPMS به مدیریت منظم و هوشمندانه فعالیت‌های سازمان کمک شایانی می‌کنه.۱۲. صف پیام (Message Queue) - مثل Kafka و RabbitMQصف پیام یه جورایی مثل صندوق پست برای نرم‌افزارها عمل می‌کنه. وقتی یه بخش از سیستم (Producer) می‌خواد یه پیامی (داده‌ای) رو برای بخش دیگه‌ای (Consumer) بفرسته، به جای اینکه مستقیم صداش بزنه، پیام رو تو یه "صف" می‌ذاره. اون بخش دیگه هم هر وقت آماده بود، میره و پیام‌ها رو از صف برمی‌داره و پردازش می‌کنه. این کار باعث میشه فرستنده و گیرنده از هم مستقل بشن (Decoupling). اگه گیرنده موقتاً در دسترس نباشه، پیام تو صف منتظر می‌مونه و از بین نمیره. این روش برای توزیع بار بین چند پردازشگر، افزایش مقاومت سیستم در برابر خطا، و پیاده‌سازی ارتباطات غیرهمزمان (Asynchronous) خیلی مفیده. Kafka بیشتر برای حجم بالای داده و پردازش جریانی (Streaming) استفاده میشه و خیلی مقیاس‌پذیره، در حالی که RabbitMQ یه کارگزار پیام سنتی‌تر با امکانات مسیریابی پیچیده‌تره.13. ارکستراسیون کانتینرها (Container Orchestration)امروزه خیلی از اپلیکیشن‌ها رو به صورت "کانتینر" مثلاً با Docker بسته‌بندی می‌کنیم. کانتینرها سبک، قابل حمل و ایزوله هستن. اما وقتی تعداد این کانتینرها زیاد میشه و روی چندین ماشین مختلف پخش میشن، مدیریتشون خیلی سخت میشه. اینجا "ارکستراسیون کانتینرها" مثل Kubernetes یا به اختصار K8s وارد میدون میشه Kubernetes مثل یه رهبر ارکستر برای کانتینرهای ما عمل می‌کنه. وظایفی مثل اینکه هر کانتینر روی کدوم ماشین اجرا بشه(Scheduling)، چطور بینشون بار توزیع بشه (Load Balancing)، اگه یه کانتینر خراب شد چطور جایگزین بشه(Self-healing)، و چطور نسخه‌های جدید اپلیکیشن بدون قطعی سرویس آپدیت بشن(Rolling Updates) رو به صورت خودکار انجام میده. این باعث میشه بتونیم اپلیکیشن‌های بزرگ و پیچیده رو با اطمینان و کارایی بالا روی زیرساخت‌های مختلف اجرا و مدیریت کنیم.۱۴. معماری چند مستأجری (Multi-Tenancy Architecture)در معماری چند مستأجری، یک نمونه (Instance) از نرم‌افزار به چندین مشتری یا "مستأجر" (Tenant) به طور همزمان سرویس میده، در حالی که داده‌ها و تنظیمات هر مستأجر از بقیه جدا و ایزوله نگه داشته میشه. فکر کنید یه آپارتمان دارید که چندین واحد داره. هر واحد مستأجر خودشو داره (داده‌ها و تنظیمات شخصی)، اما همه از زیرساخت مشترک ساختمون (مثل لوله‌کشی، برق، آسانسور) استفاده می‌کنن. این معماری برای ارائه‌دهندگان نرم‌افزار به عنوان سرویس (SaaS) خیلی رایجه، چون هزینه‌های زیرساخت و نگهداری رو کاهش میده (یک نرم‌افزار برای همه آپدیت میشه). چالش اصلی در این معماری، اطمینان از امنیت و ایزوله‌سازی کامل داده‌های هر مستأجر و همچنین مدیریت منابع به شکلیه که فعالیت یه مستأجر روی بقیه تأثیر منفی نذاره(Noisy Neighbor Problem)۱۵. الگوهای یکپارچه‌سازی سازمانی (Enterprise Integration Patterns - EIP)وقتی تو سازمان‌های بزرگ با چندین سیستم نرم‌افزاری مختلف (مثل CRM، ERP سیستم مالی و ... ) سروکار داریم، برقراری ارتباط و تبادل داده بین این سیستم‌ها یه چالش بزرگه. EIP مجموعه‌ای از راه‌حل‌های اثبات‌شده و بهترین تجارب برای حل مشکلات رایج در زمینه یکپارچه‌سازی سیستم‌هاست. این الگوها که توسط Gregor Hohpe و Bobby Woolf در کتاب معروفی به همین نام جمع‌آوری شدن، مثل یه زبان مشترک و جعبه ابزار برای معماران و توسعه‌دهندگانیه که می‌خوان سیستم‌های ناهمگون رو به هم متصل کنن. الگوهایی مثل Message Router چطور پیام‌ها رو به مقصد درست هدایت کنیم Content Enricher (چطور اطلاعات پیام رو قبل از ارسال غنی‌تر کنیم)، یاSplitter وAggregator (چطور پیام‌های بزرگ رو بشکنیم و بعداً دوباره جمع کنیم) مثال‌هایی از این الگوها هستن. استفاده از EIP به ساخت راه‌حل‌های یکپارچه‌سازی قوی‌تر، قابل فهم‌تر و با قابلیت نگهداری بهتر کمک می‌کنه.خب، این هم از برداشت‌های اولیه من از این ۱۵ مفهوم جذاب. امیدوارم این توضیحات ساده و در عین حال فنی و کاربردی براتون مفید بوده باشه و یه دید کلی بهتون داده باشه. قطعاً هر کدوم از این موضوعات دنیایی از جزئیات دارن که میشه ساعت‌ها در موردشون صحبت کرد. خوشحال میشم اگه شما هم تجربه یا نکته‌ای در مورد این مفاهیم دارید، در کامنت‌ها به اشتراک بذارید تا همگی بیشتر یاد بگیریم.مراجع مورد استفاده (و همچنین برای مطالعه بیشتر):صفحات ویکی‌پدیا برای هر یک از موضوعاتمستندات رسمی ابزارهایی مانند Kubernetes, Kafka, RabbitMQ, Terraformکتاب "Integration Patterns" by Gregor Hohpe and Bobby Woolfمقاله‌ها و وبلاگ‌های تخصصی در حوزه معماری نرم‌افزار مانند Martin Fowler's blog, InfoQ و DZoneدوره‌های آموزشی آنلاین مانند Coursera, Udemy, Pluralsight موفق و پیروز باشید! حسن رکن آبادی حسن رکن آبادی Sun, 11 May 2025 15:54:42 +0330