https://virgool.ir/feed/@aliipakdel98fa2026-11-11 16:10:14https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@aliipakdel98https://virgool.ir/@aliipakdel98/وقتی-نمودار-سازمانی-معماری-نرم-افزار-شما-را-می-نویسد-ncanbowovarmیک تناقض آشنافرض کنید تیم معماری یک شرکت، ماه‌ها وقت می‌گذارد و معماری میکروسرویس دقیقی طراحی می‌کند: سرویس‌های کوچک، مستقل، هرکدام با پایگاه‌داده‌ی اختصاصی خودش. مستندات آماده است، نمودارها کشیده شده‌اند و همه هم قانع شده‌اند. اما یک سال بعد، چیزی که در عمل ساخته شده، مجموعه‌ای از سرویس‌هاست که همگی به یک پایگاه‌داده‌ی مشترک وصل‌اند و هیچ‌کدام بدون هماهنگی با بقیه مستقر نمی‌شوند.چه اتفاقی افتاده است؟ معمولاً اولین حدس‌ها این‌هاست: تیم فنی به‌اندازه‌ی کافی بلد نبوده، عجله داشته‌ایم، یا انضباط مهندسی کم بوده است. اما توضیح دقیق‌تر جای دیگری است: در آن سازمان یک تیم متمرکز پایگاه‌داده وجود داشته که همه‌ی تغییرات اسکیما باید از آن عبور می‌کرده. وقتی مسیر ارتباطی سازمان این شکل باشد، پایگاه‌داده‌ی مشترک نتیجه‌ی طبیعی و اجتناب‌ناپذیر است؛ نه یک خطای مهندسی، بلکه بازتاب ساختار سازمان در کد.این دقیقاً همان مسئله‌ای است که کتاب Team Topologies نوشته‌ی Matthew Skelton و Manuel Pais به آن می‌پردازد. ادعای مرکزی کتاب ساده اما پیامدهایش گسترده است: طراحی ساختار تیم‌ها و طراحی معماری نرم‌افزار، دو مسئله‌ی جدا نیستند؛ یک مسئله‌اند که از دو زاویه دیده می‌شود.درباره‌ی این پروژهاین نوشته حاصل پروژه‌ی درس معماری نرم‌افزار من است؛ پروژه‌ای که در آن ویرایش دوم کتاب Team Topologies (منتشرشده در ۲۰۲۵) را به‌طور کامل مطالعه و تحلیل کردم.کار در سه فاز پیش رفت. در فاز اول، دو فصل ابتدایی را خواندم که پایه‌های نظری بحث را می‌سازند: مشکل نمودارهای سازمانی سنتی و قانون کانوی. فاز دوم به بخش میانی کتاب اختصاص داشت. تفکر تیم‌محور، توپولوژی‌های رایج و ضدالگوهایشان، چهار نوع تیم بنیادی، و روش انتخاب مرزهای نرم‌افزار. در فاز پایانی، بخش سوم کتاب را مطالعه کردم که درباره‌ی حالت‌های تعامل میان تیم‌ها و تکامل ساختار سازمان در طول زمان است. در هر فاز، مفاهیم هر فصل را دسته‌بندی و با مفاهیم فازهای قبل مرتبط کردم؛ چون نکته‌ی مهم این کتاب دقیقاً در پیوند میان این مفاهیم است، نه در تک‌تکشان.هدفم از این پست، خلاصه‌کردن فصل‌به‌فصل کتاب نیست. می‌خواهم چارچوب فکری‌ای را که از این مطالعه به دست آوردم منتقل کنم؛ چارچوبی که به نظرم برای هر کسی که در یک تیم نرم‌افزاری کار می‌کند . اگر کتاب را نخوانده‌اید، این متن می‌تواند نقشه‌ی راهی برای شروع باشد؛ و اگر خوانده‌اید، شاید زاویه‌ی دید متفاوتی به آن اضافه کند.قانون کانوی: مشاهده‌ای که به ابزار طراحی تبدیل شددر سال ۱۹۶۸، مل کانوی مشاهده‌ای را مطرح کرد که امروز به نام خودش شناخته می‌شود: سازمان‌ها سیستم‌هایی طراحی می‌کنند که ساختارشان کپی ساختار ارتباطی خود آن سازمان است. سال‌ها این جمله بیشتر به‌عنوان یک نکته‌ی جالب یا حتی طنزآمیز نقل می‌شد، اما نکته‌ی مهم این است که این قانون یک محدودیت است، نه یک توصیه. شما نمی‌توانید آن را نادیده بگیرید؛ فقط می‌توانید انتخاب کنید که آگاهانه یا ناآگاهانه با آن مواجه شوید.نتیجه‌ی عملی این نگاه، ایده‌ای است که کتاب آن را مانور معکوس کانوی (Reverse Conway Maneuver) می‌نامد: به‌جای اینکه معماری مطلوب را طراحی کنیم و امیدوار باشیم سازمان خودش را با آن تطبیق دهد، ابتدا ساختار تیم‌ها و مرزهای ارتباطی‌شان را طوری می‌چینیم که معماری موردنظر، خروجی طبیعی آن ساختار باشد.اینجا یک نکته‌ی ضدشهودی هم مطرح می‌شود که برایم جالب‌ترین بخش فصل‌های ابتدایی بود: در بسیاری از سازمان‌ها فرض بر این است که «ارتباط بیشتر همیشه بهتر است». کتاب استدلال می‌کند که این فرض اشتباه است. ارتباط پرحجم و بدون مرز میان همه‌ی تیم‌ها، دقیقاً همان چیزی است که معماری درهم‌تنیده تولید می‌کند. آنچه لازم است، ارتباط هدفمند و کم‌اما‌باکیفیت در مرزهای مشخص است، نه حداکثرسازی ارتباط.نکته‌ی مهم دیگر: نمودار سازمانی رسمی، تصویر واقعی ارتباطات نیست. کاری که واقعاً انجام می‌شود، در مسیرهای غیررسمی و افقی جریان دارد. بنابراین طراحی سازمان یعنی طراحی این مسیرهای واقعی، نه مرتب‌کردن جعبه‌های نمودار.تیم، کوچک‌ترین واحد تحویلاگر قرار است ساختار تیم‌ها را جدی بگیریم، اول باید تعریف کنیم «تیم» یعنی چه. کتاب اینجا موضع صریحی دارد: تیم یک گروه پایدار پنج تا نه نفره است که به‌سوی هدفی مشترک کار می‌کند، و کوچک‌ترین واحد تحویل در سازمان است. نتیجه‌ی مستقیم این تعریف، قاعده‌ای است که در بسیاری از سازمان‌ها رعایت نمی‌شود: کار هرگز نباید به افراد سپرده شود، بلکه باید به تیم‌ها سپرده شود.چرا این عدد؟ پشتوانه‌ی استدلال، محدودیت‌های شناخته‌شده‌ی ظرفیت اجتماعی انسان است که به عدد دانبار شهرت دارد. پژوهش‌های انسان‌شناسی نشان می‌دهد عمق روابطی که می‌توانیم برقرار کنیم لایه‌لایه است: حدود پنج نفر برای روابط نزدیک، حدود پانزده نفر برای اعتماد عمیق، حدود پنجاه نفر برای اعتماد متقابل، و حدود صد و پنجاه نفر برای اینکه توانایی‌هایشان را به خاطر بسپاریم. قاعده‌ی «تیم دوپیتزایی» آمازون هم بازتاب همین محدودیت است. نکته‌ی مهم این است که این محدودیت‌ها فقط برای تیم‌ها صادق نیستند؛ برای گروه‌بندی‌های بزرگ‌تر مثل دپارتمان‌ها و خطوط کسب‌وکار هم اعمال می‌شوند.سه اصل دیگر این فصل، که به نظرم بیش از خود عدد اهمیت دارند:تیم‌ها باید بلندمدت باشند و کار به سمت تیم جریان پیدا کند. الگوی رایج در بسیاری از سازمان‌ها برعکس است: تیم حول یک پروژه تشکیل می‌شود، پروژه تمام می‌شود و تیم متلاشی می‌شود. اما تیم برای رسیدن به عملکرد خوب به زمان نیاز دارد و انحلال یک تیم پرکار، نابودکردن سرمایه‌ای است که ماه‌ها برای ساختش وقت صرف شده است.هر بخش از نرم‌افزار باید دقیقاً یک مالک داشته باشد. مالکیت مشترک در عمل یعنی بی‌مالکی. این به معنای ممنوعیت مشارکت دیگران نیست، بلکه یعنی مسئولیت کیفیت و سرنوشت آن بخش روشن باشد.هر تیم باید یک «رابط تیمی» تعریف‌شده داشته باشد، چیزی که کتاب آن را Team API می‌نامد. همان‌طور که یک سرویس نرم‌افزاری رابط برنامه‌نویسی دارد، تعامل با یک تیم هم باید سطح مشخصی داشته باشد: کدی که تولید می‌کند، شیوه‌ی نسخه‌گذاری و اطلاع‌رسانی تغییرات، مستندات و راهنماهای کاربردی، شیوه‌های کاری، و کانال‌های ارتباطی. سؤال کلیدی این است: استفاده‌ی تیم‌های دیگر از این تیم چقدر آسان است؟ اگر پاسخ «سخت» باشد، مشکل معماری در راه است.بار شناختی: محدودیتی که معمولاً نادیده گرفته می‌شوداگر بخواهم تنها یک مفهوم از کل کتاب را انتخاب کنم که بیشترین تأثیر را بر نگاهم گذاشته، آن مفهوم بار شناختی تیم (Team Cognitive Load) است.ایده این است که هر تیم ظرفیت ذهنی محدودی دارد و این ظرفیت، یک منبع واقعی و قابل‌مدیریت است، درست مثل زمان یا بودجه. کتاب با وام‌گرفتن از ادبیات علوم شناختی، سه نوع بار را تفکیک می‌کند: بار ذاتی (پیچیدگی خود مسئله و دانش پایه‌ای که تیم باید داشته باشد)، بار بیرونی (پیچیدگی‌های تحمیلی محیط، مثل فرایندهای دست‌وپاگیر استقرار یا ابزارهای بد) و بار مرتبط (تلاش ذهنی‌ای که مستقیماً صرف حل مسئله‌ی کسب‌وکار می‌شود). هدف طراحی سازمان این است که بار بیرونی به حداقل برسد تا فضای ذهنی برای بار مرتبط باز شود.چرا این مفهوم اهمیت دارد؟ چون معیار روشنی برای تصمیم‌گیری به دست می‌دهد. سؤال «این سرویس چقدر باید بزرگ باشد؟» یا «این تیم چند دامنه را می‌تواند نگه دارد؟» معمولاً با معیارهای فنی مبهم پاسخ داده می‌شود. کتاب پاسخ دیگری پیشنهاد می‌کند: اندازه‌ی مسئولیت هر تیم باید با ظرفیت شناختی آن تیم تنظیم شود، نه با ملاحظات صرفاً فنی. یک قاعده‌ی سرانگشتی کاربردی هم ارائه می‌شود: هر تیم بهتر است حداکثر یک دامنه‌ی «پیچیده» را در اختیار داشته باشد.این نگاه، مکمل قانون کانوی است. کانوی می‌گوید مرزهای ارتباطی به مرزهای معماری تبدیل می‌شوند؛ بار شناختی می‌گوید آن مرزها را کجا بگذاریم.چرا یک نسخه‌ی واحد برای همه وجود نداردپیش از رسیدن به راه‌حل پیشنهادی کتاب، بخشی هست که به نظرم اغلب نادیده گرفته می‌شود: بررسی الگوهایی که در عمل شکست می‌خورند و شرایطی که موفقیت هر الگو به آن وابسته است.کتاب دو ضدالگوی رایج در طراحی تیم را معرفی می‌کند. اولی طراحی موردی و واکنشی است: تیم‌هایی که در پاسخ به یک اتفاق ساخته می‌شوند بدون آنکه به تصویر کلی روابط میان تیم‌ها فکر شود. مثال گویای کتاب همان تیم پایگاه‌داده است که بعد از یک خرابی در محیط عملیاتی تشکیل می‌شود. تصمیمی که در لحظه کاملاً منطقی به نظر می‌رسد، اما همان‌طور که در ابتدای این نوشته دیدیم، سال‌ها بعد به یک محدودیت معماری تبدیل می‌شود. ضدالگوی دوم جابه‌جایی مداوم اعضای تیم است: تیم‌های شناوری که برای هر پروژه سرهم و بعد از تحویل منحل می‌شوند و یکی دو نفر برای نگهداری باقی می‌مانند.بخش جالب‌تر، بررسی الگوهای موفق و شرایط لازم برای موفقیتشان است. مثلاً تیم‌های Feature و Product تنها زمانی جواب می‌دهند که بلوغ مهندسی بالایی وجود داشته باشد و سیستم پشتیبانی مناسبی پشتشان باشد؛ مدل SRE تنها در مقیاس بزرگ منطقی است؛ و تیم موقت DevOps تنها وقتی مفید است که مأموریت روشن و تاریخ انقضای مشخص داشته باشد، وگرنه خودش به یک سیلوی جدید تبدیل می‌شود.همین‌جا یکی از نقدهای ضمنی کتاب مطرح می‌شود که برایم آموزنده بود: مدل معروف Spotify اغلب به‌عنوان نسخه‌ای آماده کپی می‌شود، در حالی که آن مدل توصیف وضعیت یک سازمان مشخص در یک مقطع زمانی مشخص بود، نه فرمولی جهانی. حتی خود Spotify هم بعدها از آن فاصله گرفت.پس معیار انتخاب چیست؟ کتاب چند عامل را برجسته می‌کند: بلوغ فنی و فرهنگی سازمان، اندازه‌ی سازمان و مقیاس نرم‌افزار، میزان وابستگی و زمان انتظار میان تیم‌ها، و اینکه تقسیم مسئولیت‌ها واقعاً سیلوها را می‌شکند یا صرفاً جابه‌جایشان می‌کند. پیام روشن است: توپولوژی درست، تابع زمینه است؛ چیزی که برای آمازون کار می‌کند لزوماً برای سازمانی با بلوغ مهندسی متفاوت کار نمی‌کند.چهار نوع تیم، و نه بیشتربخش دوم کتاب، پیشنهاد ساختاری مشخصی ارائه می‌کند: برای ساخت و اجرای سیستم‌های نرم‌افزاری مدرن، تنها چهار نوع تیم کافی است. جذابیت این ادعا در محدودکنندگی‌اش است. کتاب می‌گوید تنوع بی‌رویه‌ی انواع تیم در سازمان‌ها خودش یکی از منابع سردرگمی و اصطکاک است.تیم جریان‌محور (Stream-aligned) ستون اصلی است: تیمی که به یک جریان مشخص از تغییر کسب‌وکار متصل است و می‌تواند به‌صورت انتها‌به‌انتها ارزش تحویل دهد. انتظار می‌رود اکثریت قاطع تیم‌های سازمان از این نوع باشند.سه نوع دیگر، فلسفه‌ی وجودی مشترکی دارند: کاهش بار شناختی تیم‌های جریان‌محور.تیم توانمندساز (Enabling) به‌صورت موقت به تیم‌های دیگر کمک می‌کند تا مهارت یا قابلیت جدیدی را کسب کنند. نکته‌ی ظریف اینجاست که موفقیت این تیم با «وابستگی» سنجیده نمی‌شود، بلکه با استقلال تیم‌هایی که کمکشان کرده است.تیم زیرسیستم پیچیده (Complicated-subsystem) جایی معنا پیدا می‌کند که بخشی از سیستم به تخصص عمیق و نادر نیاز دارد؛ مثلاً یک موتور محاسباتی سنگین یا الگوریتم تخصصی. این تیم استثناست، نه قاعده.تیم پلتفرم (Platform) سرویس‌های زیربنایی را طوری فراهم می‌کند که تیم‌های جریان‌محور بتوانند بدون درگیرشدن با جزئیات، کارشان را پیش ببرند.دو نکته درباره‌ی پلتفرم برایم مهم بود. اول، مفهوم نازک‌ترین پلتفرم قابل‌قبول (Thinnest Viable Platform): پلتفرم لزوماً یک محصول عظیم نیست و می‌تواند در ساده‌ترین حالت مجموعه‌ای از مستندات و قراردادهای روشن باشد. دوم، پلتفرم داخلی باید مثل یک محصول واقعی مدیریت شود؛ با نقشه‌ی راه، پایداری، و توجه جدی به تجربه‌ی توسعه‌دهنده. پلتفرمی که کاربرانش از آن فرار می‌کنند، پلتفرم نیست؛ یک مانع اضافی است.مرزها را کجا بگذاریم؟ مونولیت‌های پنهان و صفحه‌های شکستتا اینجا گفتیم مرز مسئولیت هر تیم باید با ظرفیت شناختی‌اش تنظیم شود. اما این هنوز یک اصل است، نه یک ابزار. سؤال عملی این است: دقیقاً کجا باید برش زد؟ این پرسش، موضوع یکی از کاربردی‌ترین فصل‌های کتاب است.نقطه‌ی شروع، یک هشدار است: مونولیت فقط «یک برنامه‌ی بزرگ» نیست. کتاب چند نوع مونولیت پنهان را فهرست می‌کند که تشخیصشان سخت‌تر است. مونولیت پایگاه‌داده‌ی مشترک، جایی که سرویس‌ها ظاهراً جدا هستند اما همه به یک اسکیما وابسته‌اند. مونولیت Build، که تغییر در یک بخش کوچک، ساخت مجدد کل سیستم را لازم می‌کند. مونولیت Release، که سرویس‌های مستقل را در یک بسته‌ی هماهنگ‌شده کنار هم مستقر می‌کند. مونولیت مدل، یعنی تحمیل یک مدل داده‌ی واحد به همه‌ی دامنه‌ها. مونولیت تفکر، یعنی استانداردسازی اجباری فناوری در کل سازمان. و حتی مونولیت فضای کاری، یعنی یک چیدمان یکسان برای همه‌ی تیم‌ها بدون توجه به نیازهای متفاوتشان.نکته‌ی مهم این است که شکستن مونولیت برنامه، اگر مونولیت استقرار یا مدل داده باقی بماند، عملاً هیچ سودی نمی‌رساند. سازمان هزینه‌ی سیستم توزیع‌شده را می‌پردازد بدون آنکه سرعت تحویل را به دست آورد.برای برش، کتاب استعاره‌ی زیبایی به کار می‌برد: صفحه‌ی شکست (Fracture Plane). سنگ‌تراش‌ها سنگ را از هر جایی نمی‌شکنند؛ درزهای طبیعی سنگ را پیدا می‌کنند و ضربه را با زاویه‌ی درست می‌زنند تا برش تمیز باشد. نرم‌افزار هم چنین درزهای طبیعی دارد. مهم‌ترین آن‌ها مرز دامنه‌ی کسب‌وکار (Bounded Context به معنای طراحی دامنه‌محور) است و کتاب توصیه می‌کند تا جای ممکن اولویت با همین باشد. اما صفحه‌های شکست دیگری هم معرفی می‌شوند که در موقعیت‌های خاص کارآمدند:الزامات قانونی و انطباق: جداکردن بخش‌هایی که مشمول مقرراتی مثل استاندارد PCI DSS هستند، تا بار ممیزی به کل سیستم سرایت نکندنرخ تغییر: بخش‌هایی که هر روز تغییر می‌کنند نباید به بخش‌هایی که سالی چند بار تغییر می‌کنند گره بخورندموقعیت جغرافیایی تیم: مرزبندی متناسب با پراکندگی تیم‌ها و اختلاف ساعتریسک: تفکیک بخش‌های پرریسک از بخش‌هایی که تغییرشان کم‌خطر استایزوله‌سازی کارایی: جداکردن بخش‌هایی که نیازهای مقیاس‌پذیری متفاوتی دارندفناوری: تفاوت بنیادی در پشته‌ی فناوری، مثل نرم‌افزار توکار در برابر ابر و موبایلپرسونای کاربر: مرزبندی بر اساس گروه‌های متفاوت کاربرانو یک هشدار متعادل‌کننده: شکستن سیستم هزینه دارد. تکه‌تکه‌کردن نادرست می‌تواند به داده‌ی تکراری، تجربه‌ی کاربری ناهماهنگ و پیچیدگی اضافه‌ی سیستم توزیع‌شده منجر شود. صفحه‌ی شکست ابزاری برای برش هوشمندانه است، نه مجوزی برای برش بیشتر.سه حالت تعامل: بخشی که کمتر درباره‌اش صحبت می‌شودتا اینجا بحث درباره‌ی این بود که چه تیم‌هایی داشته باشیم. اما بخش سوم کتاب سؤال دیگری مطرح می‌کند که به نظرم عملی‌تر و کم‌توجه‌شده‌تر است: این تیم‌ها دقیقاً چطور باید با هم تعامل کنند؟در بسیاری از سازمان‌ها، رابطه‌ی میان تیم‌ها هرگز به‌صراحت تعریف نمی‌شود. به یک تیم گفته می‌شود «شما مستقل و خودگردان هستید»، اما در عمل برای هر کاری باید با پنج تیم دیگر هماهنگ کند. کتاب برای رفع این ابهام، سه حالت تعامل تعریف می‌کند:همکاری (Collaboration) یعنی دو تیم برای مدتی نزدیک و مشترک روی چیزی کار کنند. این حالت برای کشف، نوآوری و مواجهه با ناشناخته‌ها عالی است، اما هزینه دارد: مرز مسئولیت‌ها مبهم می‌شود و بار شناختی هر دو طرف بالا می‌رود. به همین دلیل کتاب یک قید مشخص می‌گذارد: هر تیم در هر زمان حداکثر با یک تیم دیگر در حالت همکاری باشد.سرویس‌دهی (X-as-a-Service) یعنی یک تیم چیزی را به‌عنوان سرویس مصرف می‌کند و تیم دیگر آن را فراهم می‌کند، با کمترین هماهنگی روزمره. این حالت برای تحویل قابل‌پیش‌بینی مناسب است و بار شناختی هر دو طرف را پایین نگه می‌دارد اما فقط اگر مرز سرویس درست انتخاب شده باشد. سرویسی با مرز بد، جریان کار را کند می‌کند.تسهیل‌گری (Facilitating) یعنی یک تیم به تیم دیگر کمک می‌کند موانعش را بردارد. این حالت اصلی کار تیم‌های توانمندساز است و کارکرد جانبی مهمی هم دارد: تیم تسهیل‌گر چون با چند تیم در ارتباط است، می‌تواند کاستی‌های مشترک در پلتفرم یا ابزارها را کشف کند.نکته‌ای که برایم تازگی داشت، پژوهشی است که کتاب به آن اشاره می‌کند: گروه‌هایی که به‌صورت متناوب با هم تعامل داشتند، عملکرد بهتری در حل مسائل پیچیده نشان دادند نسبت به گروه‌هایی که دائماً در ارتباط بودند. این یافته با شهود رایج درباره‌ی «هرچه بیشتر با هم باشیم بهتر است» در تضاد است و پشتوانه‌ی خوبی برای منطق کلی کتاب فراهم می‌کند.سازمان به‌مثابه سیستمی که تکامل می‌یابدفصل پایانی بخش سوم، نکته‌ای را روشن می‌کند که به نظرم کلید درست‌فهمیدن کل کتاب است: این توپولوژی‌ها ایستا نیستند.ساده‌ترین اشتباه ممکن این است که کسی این کتاب را بخواند، یک نمودار جدید بکشد، همه را در چهار دسته بچیند و کار را تمام‌شده بداند. اما پیام کتاب دقیقاً برعکس است: ترکیب تیم‌ها و حالت‌های تعامل باید همراه با بلوغ فنی سازمان، رشد محصول و تغییر شرایط کسب‌وکار تغییر کند.الگوی رایج این تکامل، حرکت از کشف به تثبیت است: در ابتدا دو تیم با همکاری نزدیک شروع می‌کنند، چون هنوز نمی‌دانند مرز درست کجاست. با روشن‌ترشدن مسئله، همکاری محدودتر می‌شود و در نهایت رابطه به سرویس‌دهی تبدیل می‌شود. در یک سازمان بزرگ، این چرخه به‌طور هم‌زمان در نقاط مختلف و در مراحل متفاوت در جریان است.مفهوم دیگری که اینجا معرفی می‌شود حس‌گری سازمانی (Organizational Sensing) است: سازمان باید سازوکارهایی داشته باشد که سیگنال‌های تغییر را زودتر تشخیص دهد. کتاب فهرستی از نشانه‌های محرک تغییر ارائه می‌کند که خیلی ملموس‌اند؛ مثلاً وقتی تغییرات مربوط به یک بخش خاص همیشه به همان یک یا دو نفر ارجاع می‌شود، یا وقتی زمان تحویل تغییرات به‌مرور طولانی‌تر شده است. اینها علائم آن است که مرزهای فعلی دیگر جواب نمی‌دهند.نگاه جالب دیگر این است که اصطکاک در تعامل میان دو تیم را نباید صرفاً مشکل ارتباطی دانست؛ این اصطکاک اطلاعات است و معمولاً نشان می‌دهد یا مرز بین دو تیم اشتباه انتخاب شده یا قابلیتی در سازمان وجود ندارد.ویرایش دوم چه چیزی اضافه کرده است؟از آنجا که ویرایش دوم را مطالعه کردم، به یک اصلاح مفهومی مهم اشاره کنم. نویسندگان توضیح می‌دهند که استفاده از عبارت «تیم پلتفرم» در ویرایش اول باعث سوءبرداشت شده بود. در سازمان‌های بزرگ‌تر از حدود چهل تا پنجاه نفر، یک پلتفرم داخلی معمولاً با یک تیم هشت‌نفره اداره نمی‌شود. بنابراین در ویرایش دوم مفهوم گروه‌بندی پلتفرم (Platform Grouping) معرفی شده است: پلتفرم یک «نوع تیم» نیست، بلکه ظرفی است که چند تیم درون آن کار می‌کنند.پیامد این اصلاح، ایده‌ی سازمان فرکتالی است: اگر روی یک پلتفرم زوم کنیم، دوباره همان چهار نوع تیم را درون آن می‌بینیم. این خاصیت خودمتشابهی، مدل را در مقیاس‌های مختلف قابل‌استفاده می‌کند. ویرایش دوم همچنین مطالعات موردی تازه‌ای از سازمان‌هایی مانند EBSCO، ING، Adidas و GovTech سنگاپور اضافه کرده که نشان می‌دهد این الگوها فقط در شرکت‌های فناوری بزرگ کاربرد ندارند.از کجا شروع کنیم؟اگر بخواهیم این چارچوب را عملی کنیم، کتاب مسیر مشخصی پیشنهاد می‌کند که من آن را این‌طور جمع‌بندی می‌کنم:۱. از تیم شروع کنید، نه از نمودار. بپرسید تیم برای اینکه واقعاً بتواند مالک بخشی از نرم‌افزار باشد و بار شناختی غیرضروری نداشته باشد، به چه چیزی نیاز دارد.۲. جریان‌های تغییر را شناسایی کنید. این جریان‌ها می‌توانند بر اساس نوع کاربر، محصول، منطقه‌ی جغرافیایی یا نوع فعالیت تعریف شوند. تیم‌های جریان‌محور باید بر این جریان‌ها منطبق شوند.۳. نازک‌ترین پلتفرم قابل‌قبول را تعریف کنید. کمترین چیزی که جریان تغییر را روان می‌کند، نه بیشتر.۴. قابلیت‌های گمشده را پیدا کنید و برای پرکردن آن‌ها از تیم‌های توانمندساز استفاده کنید.۵. حالت تعامل هر جفت تیم را صریح کنید و بپذیرید که این حالت‌ها با گذشت زمان تغییر خواهند کرد.نگاه انتقادی و جمع‌بندیدر پایان، دو ملاحظه را هم باید مطرح کنم. اول اینکه کتاب چارچوبی توصیفی و مبتنی بر تجربه ارائه می‌دهد، نه روشی با ضمانت اجرا. مرز میان «تیم جریان‌محور» و «تیم زیرسیستم پیچیده» در دنیای واقعی همیشه به وضوح نمودارها نیست و تشخیص آن به قضاوت مهندسی نیاز دارد. دوم، خود کتاب هم تأکید می‌کند که این الگوها جایگزین انضباط مهندسی نیستند؛ سازمانی که تحویل مداوم، تست خودکار و تله‌متری مناسب ندارد، با تغییر نمودار تیم‌ها مشکلش حل نمی‌شود. ساختار تیم، شرط لازم است نه کافی.با این حال، مهم‌ترین چیزی که از این پروژه برایم باقی ماند، یک تغییر زاویه‌ی دید است: پیش از این، ساختار سازمانی را زمینه‌ای می‌دیدم که کار مهندسی در آن اتفاق می‌افتد. حالا آن را به‌عنوان یکی از تصمیم‌های معماری می‌بینم و شاید تصمیمی که دیرتر از همه می‌توان اصلاحش کرد. اگر قرار است معماری‌ای بسازیم که در عمل دوام بیاورد، باید سازمانی بسازیم که آن معماری، خروجی طبیعی‌اش باشد.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی است.علی پاکدلعلی پاکدلTue, 11 Aug 2026 22:23:57 +0330https://virgool.ir/@aliipakdel98/مروری-بر-سخنرانی-beyond-durability-database-resilience-and-entropy-reduction-with-write-ahead-logging-at-netflix-hg9j3eop7xh1سخنرانان: Prudhviraj Karumanchi & Vidhya Arvindرویداد: QCon San Francisco 2024لینک ویدئو: https://www.infoq.com/presentations/netflix-write-ahead-logging/معرفی سخنرانیوقتی سیستمی به ابعاد نتفلیکس می‌رسد که صدها میلیون کاربر، هزاران سرویس و ده‌ها فناوری ذخیره‌سازی مختلف از Cassandra تا کش‌های توزیع‌شده دارد، سوال‌های ساده‌ای مثل «مطمئنیم این داده واقعاً ذخیره شد؟» یا «چرا این دو نسخه از داده با هم نمی‌خوانند؟» به مسائل معماری تمام‌عیار تبدیل می‌شوند. در این ارائه از QCon سان‌فرانسیسکو ۲۰۲۴، پرودویراج کارومانچی و ویدیا آرویند، دو مهندس ارشد پلتفرم داده نتفلیکس، توضیح می‌دهند که چطور با ساختن یک سرویس عمومی «ثبت پیش‌نویس» (Write-Ahead Log یا WAL) در سطح پلتفرم، مجموعه‌ای از دردناک‌ترین مشکلات سیستم‌های توزیع‌شده مانند ازدست‌رفتن داده، واگرایی نسخه‌ها و جهش‌های چندپارتیشنی را یک بار برای همه تیم‌ها حل کرده‌اند. چیزی که این ارائه را خاص می‌کند این است که یک ایده قدیمی و اثبات‌شده از دل پایگاه‌های داده را بیرون کشیده و به‌عنوان یک بلوک معماری مستقل و قابل استفاده مجدد بازآفرینی کرده است.خلاصه و نکات اصلی سخنرانیسخنرانان از صورت‌مسئله شروع می‌کنند: در مقیاس نتفلیکس، خرابی نه استثنا بلکه وضعیت عادی است. نوشتنی که به‌ظاهر موفق بوده ممکن است در یکی از مقصدها گم شود؛ داده‌ای که باید هم در پایگاه داده اصلی و هم در کش و هم در ایندکس ثانویه بنشیند، ممکن است فقط در بعضی از آن‌ها بنشیند؛ و به مرور زمان «آنتروپی» که همان واگرایی خاموش بین نسخه‌های مختلف یک داده است، سیستم را می‌خورد. راه‌حل سنتی این بوده که هر تیم برای خودش منطق retry و صف و ترمیم بنویسد؛ نتیجه، ده‌ها پیاده‌سازی ناسازگار از یک مسئله واحد بود.ایده مرکزی ارائه ساده و قدرتمند است: هر جهش (Mutation) پیش از اعمال، ابتدا در یک لاگ بادوام ثبت شود و سپس از آنجا با تضمین، به مقصد یا مقصدهایش برسد. معماری سرویس WAL از چند جزء تشکیل شده که تفکیک مسئولیت تمیزی دارند: پردازشگر پیام که جهش‌ها را دریافت و در صف بادوام ثبت می‌کند، مصرف‌کننده‌ای که آن‌ها را به مقصدها می‌رساند، و یک Control Plane برای پیکربندی و پایش. نکته معمارانه کلیدی، «مقصدهای اتصال‌پذیر» (Pluggable Targets) است: همان لوله واحد می‌تواند جهش‌ها را به Cassandra، به کش، به ناحیه جغرافیایی دیگر یا به هر ذخیره‌گاه دیگری برساند؛ یعنی WAL از یک ابزار دوام داده، به ستون فقرات تکثیر بین‌سیستمی و بازسازی داده تبدیل می‌شود. بخش قابل‌توجهی از ارائه هم صادقانه به حالت‌های خرابی خود این سیستم می‌پردازد: هجوم ناگهانی ترافیک، مصرف‌کننده‌های کند، پیام‌های سمی و خطاهای ماندگار، و سازوکارهایی مثل صف‌های تأخیری و جداسازی، که برای هر کدام طراحی شده‌اند. بهای این معماری هم پنهان نمی‌شود: سازگاری نهایی به‌جای فوری، کمی تأخیر اضافه و هزینه عملیاتی یک سرویس جدید.برداشت و تحلیل شخصیدو درس از این ارائه برای من پررنگ‌تر از بقیه بود. اول، قدرت «انتزاع در سطح پلتفرم»: نتفلیکس به‌جای آن‌که به صد تیم آموزش بدهد چطور نوشتن مطمئن پیاده کنند، مسئله را یک بار در قالب سرویسی با قرارداد ساده حل کرده است. این همان تفکری است که پشت مفهوم «مسیر هموار» (Paved Path) قرار دارد و به‌گمانم مهم‌ترین الگوی معماری سازمانی دهه اخیر است: پیچیدگی را به داخل پلتفرم ببر تا تیم‌های محصول با ذهنی آزاد کار کنند. دوم، بازیافت ایده‌های کهنه: WAL دهه‌هاست قلب هر پایگاه دادهٔجدی است؛ کاری که نتفلیکس کرده «اختراع» نیست، «تغییر مقیاسِ» یک الگوی اثبات‌شده است — از داخل یک پروسه به کل یک اکوسیستم. این نگاه برای ما هم آموزنده است: قبل از ساختن راه‌حل بدیع، بپرسید کدام الگوی چهل‌ساله دارد همین مسئله را در لایه‌ای دیگر حل می‌کند. اگر بخواهم نقدی هم بکنم، این است که ارائه درباره هزینه نگهداری چنین سرویسی برای سازمان‌های کوچک‌تر کم می‌گوید؛ چیزی که خودشان هم تلویحاً می‌پذیرند این است که این معماری وقتی می‌ارزد که تعداد مصرف‌کننده‌هایش از حدی بگذرد.شاید هیچ‌وقت WAL اختصاصی نسازید، اما الگوهای این ارائه در مقیاس‌های بسیار کوچک‌تر هم کار می‌کنند. اگر جایی در سیستم شما یک نوشتن باید به چند مقصد برسد، به‌جای نوشتن مستقیم و دعاکردن، الگوی مشابهی مثل Transactional Outbox یا یک صف بادوام میانی بگذارید تا تحویل تضمین‌شده و قابل‌تکرار شود. برای بازی‌های آنلاین این سناریو کاملاً ملموس است: رویدادهای اقتصاد درون بازی (خرید، جایزه، ارتقا) دقیقاً همان جهش‌های حساسی هستند که نه باید گم شوند و نه دو بار اعمال شوند؛ ترکیب لاگ بادوام با مصرف‌کننده idempotent همان تضمینی را می‌دهد که نتفلیکس برای داده‌هایش می‌خواهد. الگوی «ترمیم آنتروپی» هم مستقیم قابل استفاده است: یک job دوره‌ای که نسخه‌های مختلف داده را مقایسه و واگرایی‌ها را گزارش یا ترمیم می‌کند، برای هر سیستمی که کش یا ایندکس ثانویه دارد، بیمه‌نامه ارزانی است.جمع‌بندیاین ارائه نمونه خوبی از معماری «بالغ» است: نه شیفته فناوری جدید، نه اسیر پیچیدگی نمایشی؛ فقط بازشناسی یک الگوی کلاسیک و بالابردن آن به سطحی که کل سازمان از آن سود ببرد. درس‌های کلیدی: دوام و سازگاری داده را به امید کد اپلیکیشن رها نکنید و آن را به زیرساختی صریح بسپارید؛ مسائل تکرارشونده را یک بار و در سطح پلتفرم حل کنید؛ برای خرابی مصرف‌کننده‌ها و پیام‌های سمی از روز اول طرح داشته باشید؛ و بین سازگاری فوری و تاب‌آوری، آگاهانه و صریح انتخاب کنید. برای هر مهندسی که با داده‌های حیاتی در سیستم‌های توزیع‌شده سروکار دارد، این پنجاه دقیقه سرمایه‌گذاری پرسودی است.اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است. علی پاکدلعلی پاکدلSat, 11 Jul 2026 22:55:14 +0330https://virgool.ir/@aliipakdel98/مروری-بر-سخنرانی-an-introduction-to-residuality-theory-xpo2hgzalrvvسخنران: Barry O'Reillyرویداد: NDC London 2024لینک ویدئو: https://www.youtube.com/watch?v=_MPUoiG6w_Uمعرفی سخنرانیدر این سخنرانی، به‌جای معرفی یک ابزار یا الگوی جدید، خود شیوه فکرکردن ما به طراحی را به چالش می‌کشد. «نظریه باقی‌مانده‌ها» (Residuality Theory) از بری اورایلی از این جنس است. اورایلی سال‌ها معمار سیستم‌های سازمانی بزرگ بوده و بعد برای پاسخ به یک سوال آزاردهنده به برگشته است: چرا معماری‌هایی که با دقت طراحی می‌کنیم، در برخورد با واقعیت این‌قدر زود می‌شکنند؟ پاسخ او تلفیقی غیرمنتظره از معماری نرم‌افزار و علم سیستم‌های پیچیده است و این سخنرانی، بهترین نقطه ورود به آن است.خلاصه و نکات اصلی سخنرانیاستدلال اورایلی از یک مشاهده ساده شروع می‌شود: نرم‌افزار، سیستمی «مرتب» (Ordered) است (قطعی و قابل تحلیل) اما در محیطی «پیچیده» (Complex) زندگی می‌کند: بازار، رقبا، قانون‌گذار، کاربران و مدیرانی که رفتارشان پیش‌بینی‌ناپذیر است. او این وضعیت دوگانه را «هایپرلیمینال» می‌نامد. رویکرد سنتی ما فرض می‌کند آینده قابل استخراج از ذی‌نفعان است؛ در حالی که در محیط پیچیده، مهم‌ترین اتفاقات آن‌هایی هستند که هیچ‌کس پیش‌بینی نکرده است.جایگزین پیشنهادی او چنین است: طراحی را با یک «معماری ساده‌لوحانه» شروع کنید؛ همان طرح اولیه‌ای که با دانش امروز می‌کشید. سپس به‌جای افزودن نیازمندی‌های بیشتر، سیستم را زیر رگبار «استرسورها» بگیرید: اگر تأمین‌کننده اصلی ورشکست شود چه؟ اگر بار سیستم ده برابر شود؟ اگر قانون جدیدی مدل درآمد را ممنوع کند؟ اگر رقیبی سرویس را رایگان عرضه کند؟ برای هر استرسور بررسی می‌کنید چه چیزی از معماری «باقی می‌ماند» و طرح را طوری اصلاح می‌کنید که باقی‌مانده کارآمدتری داشته باشد. ابزار عملی این کار «ماتریس وقوع» (Incidence Matrix) است: جدولی از استرسورها در برابر اجزای سیستم که نشان می‌دهد هر شوک به کدام اجزا سرایت می‌کند. این ماتریس ساختار پنهان و اتصال‌های واقعی سیستم را آشکار می‌کند. ادعای جسورانه و جالب اورایلی، که آن را با پژوهش دانشگاهی هم محک زده، این است که تمرین‌دادن معماری با استرسورهای تصادفی، مثل آموزش شبکه عصبی، سیستم را در برابر شوک‌های «دیده‌نشده» هم مقاوم‌تر می‌کند؛ چون آنچه واقعاً بهبود می‌یابد، ساختار اتصالات درونی سیستم است، نه پاسخ به تک‌تک سناریوها.برداشت و تحلیل شخصیاولین بار که این سخنرانی را دیدم، حس کردم کسی بالاخره برای شهودی که هر معمار باتجربه‌ای دارد (این‌که طرح اول همیشه غلط است) یک چارچوب نظری و قابل آموزش ساخته است. زیبایی نظریه باقی‌مانده‌ها این است که عدم قطعیت را نه دشمنی که باید حذف شود، بلکه ماده اولیه طراحی می‌داند. مقایسه آن با رویکردهای رایج هم روشنگر است: تحلیل ریسک سنتی فقط ریسک‌های «محتمل و شناخته‌شده» را می‌بیند، اما استرسورهای اورایلی عمداً تصادفی و حتی نامعقول انتخاب می‌شوند، چون هدف، پیش‌بینی نیست؛ ورزیده‌کردن ساختار است. البته نقدی هم دارم: فرایند کامل آن برای پروژه‌های کوچک شاید سنگین باشد و مهارت تسهیلگری قابل‌توجهی می‌خواهد تا جلسات استرسور به فهرست نگرانی‌های تکراری تبدیل نشود. اما حتی نسخهٔ سبک آن هم از هیچ‌چیز بهتر است.عملی‌ترین کاربرد این ایده‌ها در فاز طراحی اولیه و بازبینی‌های معماری است. می‌توانید کارگاه نیم‌روزه‌ای برگزار کنید: معماری فعلی یا پیشنهادی را روی تخته بکشید، از اعضای تیم (و نه فقط فنی‌ها) بخواهید بیست استرسور بنویسند و سپس ماتریس وقوع را پر کنید. جاهایی که یک استرسور به چندین جزء سرایت می‌کند، اتصال‌های پنهان شماست؛ همان‌جا باید مرز، انتزاع یا افزونگی اضافه کنید. این تمرین به‌خصوص پیش از تصمیم‌های گران‌برگشت (انتخاب پلتفرم، مدل استقرار، وابستگی به یک فروشنده خاص) ارزش واقعی دارد و خروجی‌اش را می‌توان مستقیم به ADRها برد.جمع‌بندینظریه باقی‌مانده‌ها به ما می‌گوید معماری خوب آن نیست که برای نیازمندی‌های امروز بهینه باشد؛ آن است که بعد از شوک‌های فردا، چیز مفیدی از آن باقی بماند. درس‌های کلیدی: به‌جای پیش‌بینی آینده، ساختار را در برابر تصادف ورزیده کنید؛ اتصال‌های پنهان را با استرسور آشکار کنید؛ و طرح اول را همیشه پیش‌نویس بدانید. این سخنرانی برای هر کسی که در محیطی بی‌ثبات نرم‌افزار می‌سازد، دیدنی و شاید ضروری است.اين مطلب، بخشي از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است.علی پاکدلعلی پاکدلSat, 11 Jul 2026 22:44:03 +0330https://virgool.ir/@aliipakdel98/مروری-بر-سخنرانی-architectural-decisions-in-modern-software-development-zfhqeephzhxqسخنران: Andrew Harmel-Lawرویداد: Global Software Architecture Summit (GSAS) 2024لینک ویدئو: https://www.youtube.com/watch?v=aMKUr5b8Fnwمعرفی سخنرانیاندرو هارمل‌لا در این سخنرانی در اجلاس جهانی معماری نرم‌افزار در بارسلونا، سراغ موضوعی می‌رود که یکی از مهم‌ترین بخش‌های معماری است: نه «چه تصمیمی بگیریم»، بلکه «چطور و توسط چه کسی تصمیم گرفته شود».خلاصه و نکات اصلی سخنرانیهارمل‌لا از تعریف شروع می‌کند: به قول گریدی بوچ، معماری همان «تصمیم‌های مهم طراحی» است و اهمیت را «هزینه تغییر» می‌سنجد. پس هر جا تصمیمی گران‌برگشت گرفته می‌شود، دارد معماری اتفاق می‌افتد؛ چه معماری رسمی در اتاق باشد چه نباشد. او سپس دو الگوی سنتی تصمیم‌گیری را کالبدشکافی می‌کند. الگوی اول «برج عاج» است: معمار یا کمیته معماری تصمیم می‌گیرد و تیم‌ها اجرا می‌کنند. این الگو گلوگاه می‌سازد، تصمیم‌ها را از واقعیت کد دور می‌کند و توسعه‌دهندگان را به مجریان بی‌انگیزه تبدیل می‌کند. الگوی دوم واگذاری کامل به تیم‌های خودمختار است که در عمل به ناسازگاری، دوباره‌کاری و ازدست‌رفتن تصویر کلان می‌انجامد. نکته ظریف سخنرانی این است که هر دو الگو در یک چیز مشترک‌اند: جریان یادگیری و اطلاعات را قطع می‌کنند.پیشنهاد او «فرایند مشورت» است با یک قاعده ساده اما رادیکال: هر کسی می‌تواند تصمیم معماری بگیرد، به شرط آن‌که پیش از تصمیم، با دو گروه مشورت کند — کسانی که از تصمیم اثر می‌پذیرند و کسانی که در آن موضوع تخصص دارند. مشورت الزامی است اما تبعیت از آن نه؛ تصمیم‌گیرنده پس از شنیدن، خودش تصمیم می‌گیرد و مسئولیتش را می‌پذیرد. این فرایند با چند سازوکار پشتیبان کامل می‌شود: ثبت تصمیم‌ها در قالب ADR (سوابق تصمیم معماری)، جلسه هفتگی «انجمن مشورتی معماری» برای گفت‌وگوی شفاف، و اصول فنی تیم‌محور که چارچوب تصمیم‌ها را می‌سازند. هارمل‌لا تأکید می‌کند که هدف، تصمیمِ «بی‌نقص» نیست؛ هدف تصمیم‌گیری سریع، برگشت‌پذیر و یادگیرنده است، چون در سیستم‌های اجتماعی‌فنی، بازخورد سریع از کمال‌گرایی ارزشمندتر است.برداشت و تحلیل شخصیچیزی که این سخنرانی را از یک بحث فرایندی خشک نجات می‌دهد، درک عمیق هارمل‌لا از روان‌شناسی سازمان است. او صادقانه می‌گوید سخت‌ترین بخش این تحول، فنی نیست؛ ترس توسعه‌دهنده از پذیرش مسئولیت و ترس معمار از واگذاری قدرت است. به نظرم این دقیق‌ترین توصیف از وضعیت بسیاری از سازمان‌های ماست، جایی که «تأیید معماری» به آیینی زمان‌بر تبدیل شده که نه کیفیت می‌آورد و نه چابکی. نکته دیگری که برایم جالب بود، پیوند این ایده با مفهوم جریان (Flow) است: در دنیایی که تحویل مداوم و تیم‌های محصول‌محور استاندارد شده‌اند، تصمیم‌گیری متمرکز آخرین گلوگاه باقی‌مانده است. هارمل‌لا در واقع می‌گوید معماری هم باید مثل استقرار، «توزیع‌شده» شود؛ و معمار به‌جای دروازه‌بان، باید تسهیلگر و باغبان زمینه تصمیم‌گیری باشد.پیاده‌سازی این ایده‌ها لازم نیست انقلابی باشد. قدم اول که همین امروز قابل اجراست، جدی‌گرفتن ADRهاست: هر تصمیم مهم، در یک سند کوتاه با زمینه، گزینه‌ها و نتیجه ثبت شود و در مخزن کد کنار خود کد زندگی کند. قدم دوم، راه‌اندازی یک جلسه مشورتی دوهفتگی است که در آن تصمیم‌های در جریان مطرح می‌شوند؛ نه برای تأییدگرفتن، بلکه برای شنیدن دیدگاه‌ها. برای تیم‌هایی که اغلب ساختارهای سلسله‌مراتبی دارند، شاید شروع تدریجی بهتر جواب بدهد: ابتدا دامنه مشخصی از تصمیم‌ها (مثلاً انتخاب کتابخانه‌ها و طراحی APIهای داخلی) به تیم‌ها واگذار شود و با بلوغ فرهنگ مشورت، دامنه گسترش یابد. تجربهٔ سازمان‌هایی که این مسیر را رفته‌اند نشان می‌دهد کیفیت تصمیم‌ها نه‌تنها افت نمی‌کند، بلکه به‌خاطر نزدیکی تصمیم‌گیرنده به مسئله، بهتر هم می‌شود.جمع‌بندیاین سخنرانی یادآوری می‌کند که معماری نرم‌افزار پیش از آن‌که مجموعه‌ای از دیاگرام‌ها باشد، مجموعه‌ای از تصمیم‌هاست؛ و کیفیت یک سیستم در بلندمدت، تابع کیفیتِ «فرایند» تصمیم‌گیری آن است. درس کلیدی: تصمیم‌گیری را به نزدیک‌ترین نقطه به مسئله ببرید، مشورت را اجباری و اطاعت را اختیاری کنید، و همه‌چیز را شفاف ثبت کنید. برای هر معمار یا مدیر فنی که حس می‌کند خودش گلوگاه سازمانش شده، این ویدیو می‌تواند نقطهٔ شروع یک تغییر جدی باشد.اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است.علی پاکدلعلی پاکدلSat, 11 Jul 2026 22:36:59 +0330https://virgool.ir/@aliipakdel98/مروری-بر-سخنرانی-complexity-is-the-gotcha-of-event-driven-architecture-zekjeu3ftlacسخنران: David Boyneرویداد: GOTO EDA Day London 2024لینک ویدئو: https://www.youtube.com/watch?v=VLUvfIm9wnQمعرفی سخنرانیمعماری رویدادمحور (Event-Driven Architecture) در چند سال اخیر به یکی از پرطرفدارترین سبک‌های معماری تبدیل شده است؛ وعده‌اش هم وسوسه‌کننده است: سرویس‌هایی مستقل که به‌جای فراخوانی مستقیم یکدیگر، فقط رویداد منتشر می‌کنند و هر مصرف‌کننده‌ای آزاد است هر طور می‌خواهد واکنش نشان دهد. اما دیوید در این سخنرانی در رویداد تخصصی GOTO EDA Day لندن، روی دیگر سکه را نشان می‌دهد: همان جادویی که سیستم شما را منعطف می‌کند، اگر مهارش نکنید، آن را به کلافی سردرگم از رویدادهای بی‌صاحب و جریان‌های نامرئی تبدیل می‌کند. بوین سال‌ها تجربه کار با تیم‌های واقعی را دارد و همین باعث شده حرف‌هایش کمتر شبیه تبلیغ و بیشتر شبیه گزارشی صادقانه از میدان باشد.خلاصه و نکات اصلی سخنرانیبوین بحث را از جذابیت‌های واقعی EDA شروع می‌کند: جداسازی زمانی و مکانی سرویس‌ها، مقیاس‌پذیری مستقل، امکان افزودن مصرف‌کننده جدید بدون دست‌زدن به تولیدکننده، و هم‌راستایی طبیعی با رویدادهای دنیای کسب‌وکار. اما بلافاصله سراغ نکته اصلی می‌رود: پیچیدگی در EDA ناگهانی نمی‌آید، بلکه آرام‌آرام و رویداد به رویداد انباشته می‌شود. تیمی که با ده رویداد شروع کرده، دو سال بعد با صدها نوع رویداد روبه‌روست که هیچ‌کس فهرست کاملشان را ندارد: رویدادهایی با نام‌های ناسازگار، اسکیماهای مستندنشده، رویدادهای تکراری که چند تیم بی‌خبر از هم منتشر می‌کنند، و مصرف‌کنندگانی که کسی نمی‌داند به چه چیزی وابسته‌اند. جریان کنترل که در سیستم همزمان با یک پشته فراخوانی قابل ردیابی بود، حالا در دل بروکرها و صف‌ها پخش شده و پاسخ به ساده‌ترین سوال «اگر این رویداد را تغییر بدهم چه می‌شکند؟» به تحقیقی چندروزه تبدیل می‌شود.هسته پیشنهادی سخنرانی این است که رویدادها را باید مثل API عمومی و به‌عنوان «قرارداد» جدی بگیریم، نه پیام‌هایی درجه‌دو. این یعنی چند تمرین مشخص: طراحی آگاهانه رویدادها (تصمیم صریح بین رویداد لاغر صرفاً اعلانی و رویداد چاق حامل وضعیت، چون هر کدام نوع متفاوتی از وابستگی می‌سازد)، قراردادهای اسکیمای صریح و نسخه‌بندی‌شده، قواعد نام‌گذاری سراسری، و مهم‌تر از همه، مالکیت روشن: هر رویداد باید تیم صاحب و پاسخ‌گو داشته باشد. بوین روی «کشف‌پذیری» تأکید ویژه دارد (مصرف‌کننده بالقوه باید بتواند بفهمد چه رویدادهایی وجود دارند، چه معنایی دارند و اسکیمایشان چیست) و اینجاست که ابزارهایی مثل EventCatalog و رجیستری اسکیما از «امکانات لوکس» به زیرساخت حیاتی تبدیل می‌شوند. پیام پایانی او درباره حاکمیت (Governance) است: نه کمیته‌های سنگین، بلکه گاردریل‌های سبک و خودکار (استانداردها، قالب‌ها و بررسی‌های خودکار در CI) که بگذارند تیم‌ها سریع بمانند اما آشوب تولید نکنند. برداشت و تحلیل شخصیچیزی که این سخنرانی را برای من ارزشمند می‌کند، جابه‌جاکردن محل بحث است: بیشتر محتوای آموزشی EDA درباره «ساختن» است مانند بروکر کدام باشد و الگوی Saga چطور پیاده شود اما بوین درباره «زیستن» با EDA حرف می‌زند؛ درباره سال دوم و سوم، وقتی هیجان اولیه فروکش کرده و هزینه واقعی خودش را نشان می‌دهد. بوین نشان می‌دهد این پیچیدگی جابه‌جاشده دقیقاً کجا می‌نشیند (در دانش سازمانی). در سیستم رویدادمحور، معماری واقعی نه در کد که در مجموعه قراردادهای بین تیم‌هاست، و اگر این قراردادها مستند و مدیریت نشوند، شما عملاً معماری‌ای دارید که فقط در ذهن چند نفر وجود دارد. به نظرم درس بزرگ‌تر این است که مستندسازی در EDA برخلاف تصور رایج، یک کار «بعداً انجام می‌دهیم» نیست؛ بخشی از خود معماری است.اگر همین حالا سیستم رویدادمحور دارید یا در حال طراحی آن هستید، چند اقدام مشخص از دل این سخنرانی درمی‌آید. اول، قبل از نوشتن حتی یک رویداد جدید، سند کوتاهی از قواعد نام‌گذاری و ساختار رویدادها بنویسید و آن را در قالب یک قالب آماده (Template) به تیم‌ها بدهید؛ هزینه‌اش یک روز است و جلوی سال‌ها ناسازگاری را می‌گیرد. دوم، یک کاتالوگ رویداد راه بیندازید که برای هر رویداد، مالک، اسکیما، نسخه و مصرف‌کنندگان شناخته‌شده را ثبت کند و به‌روزماندنش را در فرایند بازبینی کد اجباری کنید. سوم، برای تغییر اسکیماها از همان ابتدا سیاست نسخه‌بندی تعیین کنید؛ تجربه نشان داده «فعلاً نسخه نمی‌خواهیم» گران‌ترین جمله EDA است. در پروژه‌هایی مثل بازی‌های آنلاین که رویدادهای حیاتی فراوانی دارند این نظم از روز اول تعیین می‌کند که دو سال بعد می‌توانید ویژگی جدید را در یک هفته اضافه کنید یا باید یک ماه باستان‌شناسی رویدادها انجام دهید.جمع‌بندیسخنرانی بوین یادآوری به‌موقعی است برای همه ما که فریفته زیبایی معماری رویدادمحور شده‌ایم: EDA پیچیدگی را از لحظه استقرار به دوران بهره‌برداری منتقل می‌کند و اگر برای آن دوران برنامه نداشته باشید، بدهی فنی‌تان به‌جای کد، در نقشه ذهنی سازمان انباشته می‌شود. درس‌های کلیدی: رویداد یعنی قرارداد عمومی، پس مثل API با آن رفتار کنید؛ کشف‌پذیری و مالکیت را از روز اول بسازید؛ و حاکمیت را نه با کمیته، که با گاردریل‌های خودکار اعمال کنید. برای هر تیمی که بیش از ده‌ها نوع رویداد در تولید دارد، این ویدیو کمتر از یک ساعت وقت می‌گیرد و احتمالاً ماه‌ها دردسر آینده را کم می‌کند.اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است.علی پاکدلعلی پاکدلSat, 11 Jul 2026 22:30:10 +0330https://virgool.ir/@aliipakdel98/مروری-بر-سخنرانی-microservices-where-did-it-all-go-wrong-jxu0jaturh7dسخنران: Ian Cooperرویداد: GOTO Copenhagen 2024لینک ویدئو: https://www.youtube.com/watch?v=j2AQ9eTZ3-0معرفی سخنرانیاگر در ده سال گذشته در صنعت نرم‌افزار کار کرده باشید، تقریباً غیرممکن است که با موج میکروسرویس‌ها برخورد نکرده باشید؛ موجی که با وعده استقلال تیم‌ها، استقرار مستقل و مقیاس‌پذیری بی‌پایان شروع شد و در بسیاری از سازمان‌ها به سیستم‌هایی پیچیده، کند و شکننده ختم شد. یان کوپر در این سخنرانی سراغ سوالی می‌رود که خیلی از ما جرئت پرسیدنش را نداشتیم: کجای راه را اشتباه رفتیم؟ نکته جذاب این است که کوپر مخالف میکروسرویس نیست؛ او مدافع نسخه «درست» این ایده است و دقیقاً به همین دلیل نقدش شنیدنی از آب درآمده است.خلاصه و نکات اصلی سخنرانیکوپر بحث را با تاریخچه شروع می‌کند و نشان می‌دهد میکروسرویس‌ها از خلأ نیامده‌اند؛ ریشه آن‌ها در SOA، در ایده Bounded Context از طراحی دامنه‌محور (DDD) و در نیاز سازمان‌های بزرگی مثل آمازون و نتفلیکس به مقیاس‌دادن «سازمان» است، نه صرفاً نرم‌افزار. تعریف کلاسیک جیمز لوئیس و مارتین فاولر هم همین را می‌گوید: سرویس‌هایی که حول قابلیت‌های کسب‌وکار شکل می‌گیرند و به‌طور مستقل قابل استقرارند. مشکل از جایی شروع شد که صنعت این «چرا» را فراموش کرد و فقط «چطور» را کپی کرد.به روایت کوپر، بزرگ‌ترین خطای رایج، تفسیر واژه «میکرو» به‌معنای «هرچه کوچک‌تر بهتر» بود. تیم‌ها به‌جای تقسیم سیستم بر اساس مرزهای دامنه، آن را بر اساس موجودیت‌های داده‌ای (Entity Service) خرد کردند: سرویس مشتری، سرویس سفارش، سرویس محصول؛ سرویس‌هایی بی‌رفتار و صرفاً CRUD که برای انجام هر کار معناداری باید با هم صحبت کنند. نتیجه این کار همان چیزی است که کوپر و دیگران «مونولیت توزیع‌شده» می‌نامند: سیستمی که همه اتصالات و وابستگی‌های یک مونولیت را دارد، اما به‌جای فراخوانی تابع در حافظه، از شبکه با همه خطاها، تأخیرها و پیچیدگی‌هایش عبور می‌کند. به تعبیر خود او، ما پیچیدگی را حذف نکردیم؛ فقط آن را از داخل کد به بین سرویس‌ها منتقل کردیم، جایی که دیدن و دیباگ‌کردنش به‌مراتب سخت‌تر است.نکته کلیدی دیگر سخنرانی، هزینه عملیاتی این سبک معماری است: زیرساخت مشاهده‌پذیری، ردیابی توزیع‌شده، سازگاری نهایی (Eventual Consistency)، تراکنش‌های توزیع‌شده و بار شناختی سنگینی که روی تیم‌ها می‌گذارد. راه‌حل پیشنهادی کوپر بازگشت به اصول است: سرویس‌ها را حول Bounded Contextها طراحی کنید، از دانه‌بندی درشت‌تر شروع کنید و اگر مقیاس سازمانی‌تان ایجاب نمی‌کند، اصلاً با یک مونولیت ماژولار شروع کنید که مرزهای داخلی تمیزی دارد و در آینده قابل تفکیک است.برداشت و تحلیل شخصیچیزی که این سخنرانی را برای من متمایز می‌کند، صداقت تاریخی آن است. کوپر نمی‌گوید میکروسرویس بد است، بلکه می‌گوید میکروسرویس پاسخ به یک مسئله مشخص است: وقتی تعداد تیم‌ها آن‌قدر زیاد شده که هماهنگی برای استقرار مشترک، گلوگاه سازمان شده است. اگر این مسئله را ندارید، دارید هزینه راه‌حل مسئله دیگران را می‌پردازید. به نظرم عمیق‌ترین درس سخنرانی این است که معماری پیش از آن‌که تصمیمی فنی باشد، تصمیمی سازمانی است؛ همان چیزی که قانون کانوی سال‌هاست به ما یادآوری می‌کند. تجربه خودم هم همین را تأیید می‌کند: تیم‌های پنج‌نفره‌ای که بیست سرویس را نگهداری می‌کنند، عملاً بیشتر وقتشان صرف زیرساخت می‌شود تا ارزش کسب‌وکار.این سخنرانی برای دو گروه کاربرد مستقیم دارد. گروه اول تیم‌هایی هستند که در آستانه شروع پروژه جدیدند: پیش از انتخاب میکروسرویس، صادقانه بپرسید چند تیم دارید، چند بار در روز نیاز به استقرار مستقل دارید و آیا زیرساخت مشاهده‌پذیری و CI/CD بالغی دارید یا نه. اگر پاسخ‌ها منفی است، مونولیت ماژولار با مرزهای دامنه‌ای روشن (مثلاً به‌کمک تفکیک ماژول‌ها و قراردادهای داخلی صریح) انتخاب عاقلانه‌تری است. گروه دوم سازمان‌هایی هستند که الان در باتلاق مونولیت توزیع‌شده گیر کرده‌اند: مسیر پیشنهادی، ادغام سرویس‌های ریز و پرگفت‌وگو در واحدهای درشت‌تر هم‌راستا با دامنه است؛ حرکتی که برخلاف تصور، معمولاً هم کارایی را بهتر می‌کند و هم سرعت توسعه را.جمع‌بندی«Microservices, Where Did It All Go Wrong» یک تسویه‌حساب صادقانه با پرهیاهوترین ترند معماری دههٔ اخیر است. درس‌های کلیدی آن روشن‌اند: میکروسرویس ابزار مقیاس‌دادن سازمان است نه مد روز؛ مرز سرویس باید مرز دامنه باشد نه مرز جدول پایگاه داده؛ و کوچک‌بودن به‌خودی‌خود فضیلت نیست، استقلال در تغییر و استقرار فضیلت است. اگر فقط یک ویدیو دربارهٔ میکروسرویس می‌خواهید ببینید، بگذارید همین باشد؛ چون به‌جای فروختن رؤیا، به شما یاد می‌دهد چه سؤال‌هایی بپرسید.اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است.علی پاکدلعلی پاکدلSat, 11 Jul 2026 22:16:14 +0330https://virgool.ir/@aliipakdel98/تجربه-مطالعه-کتاب-game-programming-patterns-d1wipwuqbcjeاین مطلب مربوط به تجربه مطالعه کتاب Game Programming Patterns نوشته‌ی رابرت نایستروم می‌باشد. این کتاب یکی از شناخته‌شده‌ترین کتاب‌ها در حوزه معماری و طراحی نرم‌افزار برای بازی‌های ویدیویی است و با استفاده از مثال‌های واقعی از توسعه بازی، الگوهای طراحی مختلف را معرفی می‌کند.دلیل انتخاب این کتاب، علاقه و فعالیت اصلی من در حوزه بازی‌سازی بود. بیشتر تجربه برنامه‌نویسی من مربوط به توسعه بازی و پیاده‌سازی سیستم‌های Gameplay و هوش مصنوعی است. به همین دلیل، احساس می‌کردم مطالعه کتابی که مستقیماً از مسائل واقعی توسعه بازی صحبت می‌کند، برایم مفیدتر از مطالعه کتاب‌های معماری عمومی خواهد بود. علاوه بر این، بارها نام این کتاب را در بین برنامه‌نویسان بازی شنیده بودم و مدت زیادی بود که قصد خواندن آن را داشتم.از این کتاب فصل‌های Architecture, Performance, and Games، Component، Event Queue، Observer، Command، State، Service Locator و Object Pool را مطالعه کردم.تجربه خواندن این کتاب برای من با بسیاری از کتاب‌های فنی دیگر متفاوت بود. معمولاً هنگام خواندن کتاب‌های معماری نرم‌افزار، مثال‌ها مربوط به سیستم‌های بانکی، فروشگاه‌های اینترنتی یا نرم‌افزارهای سازمانی هستند و گاهی ارتباط دادن آن‌ها به بازی‌سازی دشوار است. اما در این کتاب تقریباً هر مثال به مشکلی اشاره می‌کند که یک برنامه‌نویس بازی احتمالاً با آن مواجه شده است؛ از کنترل شخصیت و مدیریت انیمیشن‌ها گرفته تا سیستم صوتی، مدیریت حافظه و طراحی رفتار دشمنان.در همان فصل ابتدایی، بخشی که بیش از همه توجه من را جلب کرد، تأکید نویسنده بر سادگی بود. به عنوان یک برنامه‌نویس، بارها وسوسه شده‌ام که از همان ابتدا سیستم‌ها را بسیار انعطاف‌پذیر و عمومی طراحی کنم تا برای هر نیاز احتمالی آینده آماده باشند. اما نویسنده بارها تأکید می‌کند که معماری بیش از حد می‌تواند به اندازه نداشتن معماری مضر باشد. این بخش باعث شد به برخی تصمیم‌های گذشته خودم در پروژه‌های بازی فکر کنم؛ پروژه‌هایی که در آن‌ها زمان زیادی صرف طراحی سیستم‌های بسیار عمومی کرده بودم، در حالی که شاید هنوز نیازی به آن پیچیدگی وجود نداشت.هنگام مطالعه فصل Component، بارها به سیستم‌هایی که در پروژه‌های خودم نوشته‌ام فکر می‌کردم. توصیف کلاس‌های بزرگ و چند هزار خطی که به مرور مسئولیت‌های مختلف را به خود جذب می‌کنند، برایم کاملاً آشنا بود. احساس می‌کردم نویسنده دقیقاً مشکلاتی را توصیف می‌کند که هر برنامه‌نویس بازی بعد از مدتی با آن‌ها مواجه می‌شود. این موضوع باعث شد فصل Component را با دقت بیشتری بخوانم و حتی بعد از پایان فصل، مدتی به ساختار برخی از سیستم‌های فعلی پروژه خودم فکر کنم.در فصل Event Queue، چیزی که برایم جالب بود این بود که نویسنده فقط درباره تمیزتر شدن معماری صحبت نمی‌کند، بلکه دائماً محدودیت‌های واقعی توسعه بازی را نیز در نظر می‌گیرد؛ محدودیت‌هایی مانند عملکرد، استفاده از Threadهای مختلف و هزینه‌های مدیریت حافظه. همین نگاه عملی باعث شد احساس کنم کتاب توسط کسی نوشته شده که واقعاً سال‌ها در صنعت بازی کار کرده است، نه صرفاً یک نویسنده دانشگاهی.فصل Observer نیز تجربه مشابهی داشت. هنگام خواندن مثال سیستم Achievement، بلافاصله به سیستم‌هایی که خودم در بازی‌ها پیاده‌سازی کرده‌ام فکر کردم؛ سیستم‌هایی که به مرور وابستگی‌های زیادی پیدا می‌کنند و تغییر آن‌ها دشوار می‌شود. جالب‌ترین بخش این فصل برای من، توضیح مشکلات و معایب الگو بود. در بسیاری از منابع آموزشی، الگوهای طراحی تقریباً بدون ایراد معرفی می‌شوند، اما این کتاب دائماً تأکید می‌کند که هر راه‌حل جدید، مشکلات جدیدی نیز به همراه می‌آورد.از بین تمام فصل‌هایی که مطالعه کردم، فصل State بیش از همه برایم جذاب بود. احتمالاً دلیل آن این است که در بازی‌سازی دائماً با طراحی رفتار کاراکترها و دشمنان سر و کار داریم. هنگام خواندن مثال Heroine و اضافه شدن تدریجی قابلیت‌های جدید، بارها به یاد کدهایی افتادم که با اضافه شدن ویژگی‌های جدید، به مرور پر از شرط‌ها و حالت‌های مختلف شده بودند. احساس می‌کردم مثال‌های کتاب صرفاً مثال‌های آموزشی نیستند، بلکه از مشکلات واقعی و تجربه‌های عملی نویسنده به وجود آمده‌اند.فصل Service Locator نیز برایم جالب بود، زیرا برخلاف بسیاری از مطالب اینترنتی که این الگو را یا کاملاً خوب و یا کاملاً بد معرفی می‌کنند، نویسنده دیدگاه متعادل‌تری دارد. او نشان می‌دهد که چرا این الگو به وجود آمده، چه مزایایی دارد و در عین حال در چه شرایطی می‌تواند به یک متغیر سراسری پنهان تبدیل شود. این رویکرد واقع‌گرایانه تقریباً در تمام کتاب دیده می‌شود.در نهایت، فصل Object Pool یکی از فصل‌هایی بود که بیشترین ارتباط را با تجربه‌های شخصی من داشت. در توسعه بازی، مخصوصاً در سیستم‌هایی مانند افکت‌ها، پرتابه‌ها و ذرات، موضوع مدیریت حافظه و ایجاد و حذف مداوم اشیاء اهمیت زیادی دارد. هنگام خواندن این فصل، چند بار به پیاده‌سازی‌هایی که قبلاً انجام داده بودم فکر کردم و متوجه شدم چرا بسیاری از موتورهای بازی تا این اندازه روی استفاده مجدد از اشیاء تأکید می‌کنند.به طور کلی، تجربه خواندن این کتاب برای من بیشتر از آنکه شبیه یاد گرفتن چند الگوی طراحی جدید باشد، شبیه گفت‌وگو با یک برنامه‌نویس باتجربه بازی بود که مشکلات واقعی توسعه بازی را توضیح می‌دهد و تجربه‌های خود را در قالب الگوهای مختلف به اشتراک می‌گذارد. چیزی که بیش از همه از این کتاب در ذهنم باقی ماند، خود الگوها نبودند، بلکه شیوه فکر کردن نویسنده درباره طراحی نرم‌افزار بود؛ اینکه هر تصمیم معماری یک هزینه دارد، هیچ راه‌حل کاملی وجود ندارد و سادگی و عمل‌گرایی در بسیاری از مواقع ارزش بیشتری از پیچیدگی و انتزاع بیش از حد دارند.اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است.علی پاکدلعلی پاکدلSat, 11 Jul 2026 15:44:31 +0330https://virgool.ir/@aliipakdel98/sa-hw1-l5oa5tctzjik۱. مهندسی آشوب (Chaos Engineering)امروزه بسیاری از نرم‌افزارها و سرویس‌های آنلاین روی سیستم‌های پیچیده و توزیع‌شده اجرا می‌شوند. در چنین سیستم‌هایی ممکن است مشکلاتی مانند قطعی سرور، اختلال شبکه، افزایش ناگهانی کاربران یا خرابی بخشی از سیستم رخ دهد. مهندسی آشوب (Chaos Engineering) روشی است که به کمک آن این نوع خرابی‌ها به‌صورت عمدی و کنترل‌شده شبیه‌سازی می‌شوند تا مشخص شود سیستم در شرایط بحرانی چگونه عمل می‌کند.فرض کنید یک ماشین جدید ساخته‌اید. به جای اینکه منتظر بمانید تا در جاده و حین رانندگی تصادف کند، خودتان در پیست آزمایش با پتک به بدنه آن می‌کوبید یا ترمزها را دست‌کاری می‌کنید تا ببینید چقدر محکم است!مهندسی آشوب دقیقاً همین است. یعنی ما عمداً و در یک محیط کنترل‌شده، خرابکاری‌هایی (مثل قطع کردن یک سرور، شبیه‌سازی قطع اینترنت و یا پر کردن حافظه CPU) را وارد سیستم نرم‌افزاری خودمان می‌کنیم تا ببینیم آیا سیستم می‌تواند گلیم خودش را از آب بیرون بکشد و به کارش ادامه دهد یا کلاً منفجر می‌شود! هدف ما خرابکاری نیست، بلکه پیشگیری پیش‌دستانه (Proactive) از فاجعه است.به طور کلی، مهندسی آشوب به تیم‌های نرم‌افزاری کمک می‌کند تا قبل از وقوع بحران‌های واقعی، نقاط ضعف سیستم را شناسایی کرده و قابلیت اطمینان و تاب‌آوری نرم‌افزار را افزایش دهند.۲. بک‌اند برای فرانت‌اند (Backend for Frontend)Backend for Frontend یا به اختصار BFF یک الگوی معماری نرم‌افزار است که در آن برای هر نوع رابط کاربری یک بک‌اند اختصاصی در نظر گرفته می‌شود. ایده اصلی این است که نیازهای یک وب‌سایت، اپلیکیشن موبایل یا حتی یک دستگاه هوشمند با یکدیگر متفاوت هستند؛ بنابراین بهتر است هر کدام یک لایه بک‌اند مخصوص خود داشته باشند.در معماری‌های سنتی، همه فرانت‌اند‌ها مستقیماً با یک بک‌اند مشترک ارتباط برقرار می‌کنند. این موضوع باعث می‌شود بک‌اند مجبور باشد نیازهای مختلف و گاهی متناقض چندین نوع کاربر را پوشش دهد. در الگوی BFF، بین فرنت‌اند و سرویس‌های اصلی سیستم یک بک‌اند اختصاصی قرار می‌گیرد که فقط برای همان فرانت‌اند طراحی شده است.BFF یعنی ما به جای اینکه یک بک‌‌اند غول‌آسا داشته باشیم که سعی کند همه را راضی نگه دارد، برای هر کلاینت یک لایه بک‌‌اند اختصاصی و کوچک می‌سازیم. این لایه مانند یک «مترجم» عمل می‌کند که داده‌های خام را از میکروسرویس‌های اصلی می‌گیرد، آن‌ها را به شکلی که آن کلاینت خاص نیاز دارد فیلتر یا ترکیب می‌کند و تحویل می‌دهد.۳. هوش‌مصنوعی برای مهندسی نرم‌افزار (AI4SE)با پیچیده‌تر شدن سیستم‌های امروزی و کم شدن زمان عرضه به بازار، مهندسان نیاز به ابزارهای کمکی دارند. در اینجا اصطلاح AI4SE (مخفف AI for Systems Engineering) متولد می‌شود. به زبان ساده، در AI4SE از ابزارها و تکنیک‌های هوش مصنوعی (مثل یادگیری ماشین و پردازش داده‌ها) استفاده می‌شود تا فرآیند طراحی، ساخت، تست و نگهداری سیستم‌های پیچیده نرم‌افزاری را بهبود، سرعت و بهینه‌سازی ببخشد.در AI4SE از هوش مصنوعی برای انجام یا تسهیل کارهایی مانند تولید کد، یافتن خطاها، تولید تست، تحلیل نیازمندی‌ها و پیش‌بینی مشکلات احتمالی استفاده می‌شود. به این ترتیب، بخشی از کارهایی که قبلاً به‌صورت دستی انجام می‌شد، می‌تواند به کمک ابزارهای هوشمند سریع‌تر و دقیق‌تر انجام شود.۴. مهندسی‌ سیستم برای هوش‌مصنوعی (SE4AI)اگر در موضوع قبلی (AI4SE) از هوش مصنوعی به عنوان دستیار استفاده می‌کردیم، در SE4AI (مخفف Systems Engineering for AI) ورق کاملاً برمی‌گردد. در اینجا ما می‌خواهیم یک سیستم نرم‌افزاری بسازیم که خودش یک بخش هوش مصنوعی یا یادگیری ماشین در دلش دارد؛ مثلاً یک ماشین خودران، یک سیستم تشخیص پزشکی یا ابزار هوشمند بورس.سیستم‌های هوش مصنوعی معمولاً پیچیده‌تر از نرم‌افزارهای سنتی هستند؛ زیرا علاوه بر کد، شامل داده‌ها، مدل‌های یادگیری ماشین و فرآیندهای آموزش و به‌روزرسانی نیز می‌شوند. به همین دلیل، برای اطمینان از کیفیت، امنیت، قابلیت اطمینان و عملکرد صحیح این سیستم‌ها، باید از اصول مهندسی نرم‌افزار استفاده شود.تفاوت SE4AI با AI4SE در این است که در AI4SE، هوش مصنوعی به مهندسی نرم‌افزار کمک می‌کند؛ اما در SE4AI، مهندسی نرم‌افزار به ساخت و مدیریت سیستم‌های هوش مصنوعی کمک می‌کند.۵. عملیات یادگیری ماشین (MLOps)در دنیای مهندسی نرم‌افزار، ما سال‌هاست که از DevOps استفاده می‌کنیم تا فرآیند نوشتن کد و قرار دادن آن روی سرور را خودکار و سریع کنیم. اما وقتی پای یادگیری ماشین (Machine Learning) به میان می‌آید، قضیه خیلی پیچیده‌تر می‌شود؛ چون ما اینجا فقط با «کد» سروکار نداریم، بلکه با «کد + داده‌ها + مدل ریاضی» طرف هستیم.MLOps (مخفف Machine Learning Operations) مجموعه‌ای از روش‌ها و ابزارهاست که فرهنگ DevOps را وارد دنیای یادگیری ماشین می‌کند. هدف MLOps این است که چرخه حیات یک مدل هوش مصنوعی (از آماده‌سازی داده‌ها و آموزش مدل گرفته تا تست، ارزیابی، مستقر کردن روی سرور و پایش آن) را کاملاً خودکار و استاندارد کند تا مدل‌ها سریع‌تر و با خطای کمتر به دست کاربران برسند.در پروژه‌های یادگیری ماشین، تنها ساخت مدل کافی نیست. داده‌ها باید جمع‌آوری و آماده شوند، مدل آموزش ببیند، آزمایش شود، در محیط واقعی مستقر گردد و عملکرد آن به‌طور مداوم پایش شود. انجام دستی این مراحل زمان‌بر و پرخطا است. MLOps با استفاده از خودکارسازی، کنترل نسخه، CI/CD و پایش مداوم، این فرآیندها را ساده‌تر و قابل اعتمادتر می‌کند. از مهم‌ترین مزایای MLOps می‌توان به کاهش زمان استقرار مدل، افزایش همکاری بین تیم‌های داده و توسعه، بهبود کیفیت مدل‌ها و کاهش هزینه‌های نگهداری اشاره کرد.۶. زیرساخت به عنوان کد (IaC)Infrastructure as Code یا IaC روشی برای مدیریت و پیکربندی زیرساخت‌های فناوری اطلاعات از طریق کد است. در این رویکرد، به جای اینکه سرورها، شبکه‌ها، پایگاه‌های داده و سایر منابع به‌صورت دستی تنظیم شوند، تمام تنظیمات و مشخصات زیرساخت در قالب فایل‌های کد تعریف می‌شوند.IaC به زبان ساده‌تر می‌گوید که به جای کارهای دستی، بیایید کل ساختار زیرساخت (مثل سرورها، شبکه‌ها، لود بالانسرها و دیتابیس‌ها) را در قالب فایل‌های متنی و کد بنویسیم. ابزارهای IaC این کدها را می‌خوانند و خودکار در چند دقیقه دقیقاً همان محیطی که خواسته‌ایم را در کلود (مثل AWS یا سرورهای محلی) برای ما می‌سازند. با این کار، مدیریت زیرساخت دقیقاً مثل مدیریت کدهای یک نرم‌افزار می‌شود.مهم‌ترین مزیت IaC ایجاد یکپارچگی و تکرارپذیری است. وقتی زیرساخت از طریق کد تعریف شود، محیط‌های توسعه، تست و عملیاتی دقیقاً مشابه یکدیگر خواهند بود و مشکل «تفاوت محیط‌ها» به حداقل می‌رسد. همچنین استفاده از کنترل نسخه (Version Control) باعث می‌شود تغییرات زیرساخت قابل پیگیری و بازگشت باشند.۷. API Gateway & Service Meshدر معماری Microservices، دو فناوری مهم برای مدیریت ارتباطات وجود دارند: API Gateway و Service Mesh. این دو مفهوم گاهی شبیه به هم به نظر می‌رسند، اما وظایف متفاوتی دارند و معمولاً در کنار یکدیگر استفاده می‌شوند. وقتی یک معماری یکپارچه (Monolith) را می‌شکنیم و به کلی میکروسرویس کوچک تبدیل می‌شود، دو چالش بزرگ ارتباطی داریم:۱. کلاینت‌های بیرونی (مثل اپلیکیشن موبایل کاربر) چطور باید با این همه سرویس داخلی صحبت کنند؟۲. این میکروسرویس‌های داخلی چطور خودشان با یکدیگر امن و سریع ارتباط برقرار کنند؟برای حل این دو چالش، دو تکنولوژی متفاوت اما مکمل داریم: API Gateway و Service Mesh.API Gateway در ورودی سیستم قرار می‌گیرد و تمام درخواست‌های کاربران یا سیستم‌های خارجی را دریافت می‌کند. این لایه وظایفی مانند مسیریابی درخواست‌ها، احراز هویت، محدودسازی تعداد درخواست‌ها (Rate Limiting)، مدیریت نسخه‌های API و نظارت بر ترافیک را انجام می‌دهد. به بیان ساده، API Gateway دروازه ورود به سیستم است.در مقابل، Service Mesh برای مدیریت ارتباط بین سرویس‌های داخلی یک معماری میکروسرویسی استفاده می‌شود. این فناوری ارتباط سرویس‌ها با یکدیگر را کنترل می‌کند و قابلیت‌هایی مانند کشف سرویس‌ها، توازن بار (Load Balancing)، رمزنگاری ارتباطات، مانیتورینگ و مدیریت خطاها را فراهم می‌کند.۸. تفکیک مسئولیت دستور و پرس‌وجو (CQRS)CQRS (مخفف Command Query Responsibility Segregation) یا تفکیک مسئولیت فرمان و پرس‌وجو یک الگوی معماری نرم‌افزار است که عملیات خواندن اطلاعات (Query) را از عملیات نوشتن و تغییر اطلاعات (Command) جدا می‌کند. در این الگو، به جای استفاده از یک مدل مشترک برای خواندن و نوشتن داده‌ها، برای هر کدام مدل یا حتی پایگاه داده جداگانه در نظر گرفته می‌شود.در معماری‌های سنتی (CRUD)، یک مدل واحد هم برای خواندن و هم برای تغییر داده‌ها استفاده می‌شود. اما در سیستم‌های پیچیده، نیازهای بخش خواندن و نوشتن معمولاً متفاوت هستند. برای مثال، در یک فروشگاه اینترنتی، ممکن است ثبت سفارش (نوشتن) نیاز به پردازش تراکنش سنگین داشته باشد، اما کاربران هم‌زمان هزاران بار لیست محصولات (خواندن) را لود کنند. استفاده از یک مدل برای هر دو کار، کارایی سیستم را پایین می‌آورد.مزیت اصلی CQRS افزایش کارایی، مقیاس‌پذیری و انعطاف‌پذیری سیستم است. با این حال، پیاده‌سازی آن پیچیدگی بیشتری نسبت به معماری‌های معمولی دارد و معمولاً برای سیستم‌های بزرگ و پیچیده توصیه می‌شود.۹.معماری رویداد-محور (EDA)EDA (مخفف Event-Driven Architecture) یا معماری رویدادمحور یک الگوی معماری نرم‌افزار است که در آن اجزای سیستم از طریق رویدادها (Events) با یکدیگر ارتباط برقرار می‌کنند. رویداد به هر اتفاق مهمی در سیستم گفته می‌شود؛ مانند ثبت سفارش، پرداخت موفق، ورود کاربر یا تغییر وضعیت یک محصول.در معماری‌های سنتی، سیستم‌ها به صورت هم‌گام (Synchronous) با هم صحبت می‌کنند؛ یعنی سیستم A به سیستم B زنگ می‌زند و منتظر می‌ماند تا جواب را بگیرد. اگر سیستم B قطع باشد، کار سیستم A هم لنگ می‌ماند.اما معماری رویداد-محور (EDA) می‌گوید: سیستم‌ها باید به صورت ناهم‌گام (Asynchronous) و بر پایه رویدادها با هم ارتباط داشته باشند. رویداد یعنی «یک اتفاق مهم که در سیستم رخ داده و تمام شده است»؛ مثلاً: «کاربر دکمه خرید را زد»، «دمای سنسور به ۱۸۰ درجه رسید» یا «پرداخت موفقیت‌آمیز بود».در این معماری، فرستنده (Producer) رویداد کاری ندارد که چه کسی قرار است این پیام را بگیرد؛ او فقط رویداد را داخل یک تالار گفتگو ارسال می‌کند. گیرندگان رویداد (Consumers) که گوش‌به‌زنگ نشسته‌اند، هر زمان که آمادگی داشتند این پیام را برمی‌دارند و کار خودشان را انجام می‌دهند. فرستنده و گیرنده اصلاً همدیگر را نمی‌شناسند.۱۰. معماری بدون سرور (Serverless Architecture)Serverless Architecture یک سبک معماری است که در آن توسعه‌دهندگان بدون مدیریت مستقیم سرورها، برنامه‌های خود را توسعه و اجرا می‌کنند. در این مدل، تأمین، نگهداری، مقیاس‌پذیری و مدیریت زیرساخت بر عهده ارائه‌دهنده خدمات ابری است و توسعه‌دهندگان تنها روی منطق و کدنویسی برنامه تمرکز می‌کنند.بزرگ‌ترین اشتباه در کلمه Serverless این است که فکر کنیم «هیچ سروری در کار نیست!». در واقع، سرورها وجود دارند، اما دلیل این نام‌گذاری این است که شما به عنوان یک توسعه‌دهنده یا معمار نرم‌افزار، هیچ نیازی به دیدن، مدیریت، آپدیت یا خرید سرورها ندارید. در معماری سنتی، شما باید یک سرور مجازی اجاره می‌کردید، سیستم‌عاملش را آپدیت می‌کردید و نگران می‌شدید که اگر ترافیک بالا رفت سرور کرش نکند. اما در معماری بدون سرور، کل این دردسرها به عهده شرکت ارائه‌دهنده خدمات ابری (مثل آمازون، گوگل یا مایکروسافت) است. شما فقط کد خود را می‌نویسید و آپلود می‌کنید؛ سیستم ابری خودش به ازای هر درخواستی که سمت برنامه می‌آید، موقتاً یک سرور روشن می‌کند، کد شما را اجرا می‌کند، جواب کاربر را می‌دهد و بعد سرور را خاموش می‌کند!مزایای اصلی Serverless شامل کاهش پیچیدگی مدیریت زیرساخت، افزایش سرعت توسعه، مقیاس‌پذیری خودکار و کاهش هزینه‌های عملیاتی است. با این حال، چالش‌هایی مانند وابستگی به ارائه‌دهنده سرویس، محدودیت منابع و تأخیر اولیه اجرای سرویس‌ها (Cold Start) نیز وجود دارد.۱۱. API-First ApproachAPI-First یک رویکرد توسعه نرم‌افزار است که در آن طراحی و تعریف APIها پیش از پیاده‌سازی سایر بخش‌های سیستم انجام می‌شود. در این رویکرد، APIها به‌عنوان اجزای اصلی و پایه‌ای سیستم در نظر گرفته می‌شوند و سایر بخش‌ها مانند وب‌سایت، اپلیکیشن موبایل یا سرویس‌های دیگر بر اساس آن‌ها توسعه می‌یابند.در روش‌های سنتی، وقتی می‌خواستیم یک نرم‌افزار بسازیم، اول دیتابیس و کدهای بک‌اند را می‌نوشتیم، ظاهر برنامه را طراحی می‌کردیم و در آخر به سراغ APIها می‌رفتیم.اما رویکرد API-First دقیقاً برعکس است . این رویکرد می‌گوید: قبل از اینکه حتی یک خط کد برای برنامه بنویسید، اول باید روی طراحی، مستندسازی و ساختار مشخص API توافق کنید. در این مدل، API به عنوان یک «شهروند درجه یک» و پایه و اساس کل پروژه در نظر گرفته می‌شود. ما ابتدا یک «قرارداد» (Contract) با ابزارهایی مثل OpenAPI/Swagger می‌سازیم که می‌گوید سیستم قرار است چه ورودی و خروجی‌هایی داشته باشد، سپس همه تیم‌ها کارشان را بر اساس این قرارداد شروع می‌کنند.مزایای اصلی این رویکرد شامل توسعه سریع‌تر، قابلیت استفاده مجدد از سرویس‌ها، یکپارچگی بهتر بین سیستم‌ها، بهبود تجربه توسعه‌دهندگان و پشتیبانی مناسب از معماری‌های مدرن مانند میکروسرویس‌ها است. به همین دلیل API-First به یکی از رویکردهای رایج در توسعه سامانه‌های مدرن تبدیل شده است.۱۲. طراحی دامنه‌محور (Domain-Driven Design)Domain-Driven Design یا DDD یک رویکرد طراحی نرم‌افزار است که تمرکز اصلی آن بر درک عمیق حوزه کسب‌وکار (Domain) و مدل‌سازی نرم‌افزار بر اساس مفاهیم و قوانین آن حوزه است. در این رویکرد، توسعه‌دهندگان و متخصصان کسب‌وکار با استفاده از یک زبان مشترک (Ubiquitous Language) همکاری می‌کنند تا نرم‌افزار بیشترین تطابق را با نیازهای واقعی سازمان داشته باشد.بسیاری از پروژه‌های نرم‌افزاری به این دلیل شکست می‌خورند که برنامه‌نویسان بهترین تکنولوژی‌ها را استفاده کرده‌اند، اما دقیقاً نفهمیده‌اند که بیزینس یا همان دامنه کارفرما چطور کار می‌کند! به عنوان مثال شما نمی‌توانید یک سیستم بانکی عالی بسازید، مگر اینکه اول محاسبات پیچیده بانکی و قوانین آن را عمیقاً درک کنید.DDD می‌گوید که قلب فرآیند توسعه باید مدل‌سازی دقیق فرآیندها، قوانین و نیازمند‌ی‌های بیزینس باشد، نه مسائل فنی و دیتابیس. در این روش، برنامه‌نویسان و متخصصان بیزینس کنار هم می‌نشینند و یک زبان مشترک خلق می‌کنند. یعنی کلماتی که در کد استفاده می‌شود (مثل نام متغیرها و کلاس‌ها) باید دقیقاً همان کلماتی باشد که کارفرما در دنیای واقعی استفاده می‌کند.۱۳. معماری شش‌ضلعی (Hexagonal Architecture)معماری شش‌ضلعی یا Hexagonal Architecture یک روش طراحی نرم‌افزار است که هدفش جدا کردن منطق اصلی برنامه (Business Logic) از جزئیات فنی مثل دیتابیس، رابط کاربری و سرویس‌های بیرونی است. در این مدل، هسته‌ی برنامه در مرکز قرار دارد و همه چیز از طریق «پورت‌ها» و «آداپتورها» به آن وصل می‌شود.در معماری‌های سنتی (۳ لایه)، لایه بیزینس مستقیماً به لایه دیتابیس وصل است. این یعنی اگر بخواهید دیتابیس را عوض کنید یا پکیج جدیدی نص کنید، احتمالاً کدهای اصلی بیزینس شما دستخوش تغییر و باگ می‌شوند.اما معماری شش‌ضلعی می‌گوید: هسته اصلی برنامه باید مثل یک جزیره کاملاً مستقل در مرکز قرار بگیرد و هیچ ابزار خارجی (مثل دیتابیس، پنل وب، تلگرام بوت، یا APIهای دیگر) نباید به درون آن نفوذ کنند. هسته برنامه فقط تعدادی پورت (که در کد همان Interfaceها یا قراردادها هستند) معرفی می‌کند. ابزارهای بیرونی، آداپتور مخصوص خود را می‌نویسند تا به این پورت‌ها وصل شوند؛ درست مثل لپ‌تاپ شما که یک پورت USB (مستقل از تکنولوژی) دارد و شما می‌توانید هم موس، هم کیبورد و هم هارد اکسترنال را با آداپتورهایشان به آن وصل کنید، بدون اینکه ساختار داخلی لپ‌تاپ تغییر کند.۱۴. Event SourcingEvent Sourcing یک سبک معماری است که به جای اینکه فقط «وضعیت فعلی» سیستم را ذخیره کنیم، تمام تغییراتی که روی سیستم اتفاق می‌افتد را به شکل «رویداد» ذخیره می‌کند. یعنی به جای اینکه فقط بدانیم الان وضعیت چیست، دقیقاً می‌دانیم چه اتفاق‌هایی افتاده که ما را به این وضعیت رسانده است.در دیتابیس‌های سنتی (CRUD)، ما همیشه آخرین وضعیت یک داده را ذخیره می‌کنیم. مثلاً اگر موجودی حساب شما ۱۰۰ هزار تومان باشد و ۵۰ هزار تومان واریز کنید، عدد ۱۰۰ به ۱۵۰ تبدیل می‌شود. اگر کسی بپرسد «این ۱۵۰ هزار تومان چطور به دست آمده؟»، دیتابیس سنتی چیزی برای گفتن ندارد، مگر اینکه یک سیستم لاگ‌گیری جداگانه ساخته باشید.الگوی Event Sourcing می‌گوید: ما اصلاً وضعیت فعلی را ذخیره نمی‌کنیم؛ بلکه تمام اتفاقات و رویدادهایی که منجر به این وضعیت شده‌اند را به صورت یک زنجیره متوالی ذخیره می‌کنیم. در این معماری، دیتابیس ما یک بانک اطلاعاتی فقط‌افزودنی (Append-only) به نام Event Store است. برای به دست آوردن موجودی فعلی حساب، سیستم از نقطه صفر شروع می‌کند و تمام رویدادهای واریز و برداشت را از ابتدا تا انتها روی حساب بازیانی (Replay) می‌کند تا به عدد نهایی برسد. سیستم کنترل نسخه (مثل Git) یا دفتر کل حسابداری بهترین مثال‌های ملموس برای این الگو هستند؛ گیت کدهای نهایی را ذخیره نمی‌کند، بلکه تغییرات را نگه می‌دارد.مزیت مهم این روش این است که علاوه بر وضعیت فعلی، تاریخچه کامل هم داریم. بنابراین می‌توانیم بفهمیم چه زمانی چه اتفاقی افتاده، یا حتی وضعیت سیستم را در یک زمان خاص بازسازی کنیم. البته در عوض، طراحی و پیاده‌سازی آن پیچیده‌تر و سنگین‌تر از روش‌های سنتی است.۱۵. پلتفرم‌های Low-code/No-codeپلتفرم‌های Low-code و No-code ابزارهایی هستند که ساخت نرم‌افزار را خیلی ساده‌تر و سریع‌تر می‌کنند، طوری که لازم نیست مثل روش‌های سنتی همه‌چیز را خط‌به‌خط کدنویسی کنیم.این پلتفرم‌ها به کمک واسط‌های کاربری گرافیکی، ابزارهای کشیدن و رها کردن (Drag-and-Drop) و مدل‌سازی بصری به کاربران اجازه می‌دهند بدون درگیر شدن با پیچیدگی‌های کدنویسی، برنامه بسازند:No-Code: مخصوص افرادی است که اصلاً دانش برنامه‌نویسی ندارند. آن‌ها به کمک ابزارهای کاملاً بصری، کارهای خود را جلو می‌برند.Low-Code: به کمی دانش پایه برنامه‌نویسی نیاز دارد و به توسعه‌دهندگان حرفه‌ای کمک می‌کند تا کارهای تکراری (مثل ساخت فرم‌ها یا اتصال به دیتابیس) را با سرعت بالا (تا ۹۰٪ سریع‌تر) انجام دهند و فقط بخش‌های بسیار خاص را کدنویسی کنند.البته این ابزارها بیشتر برای اپلیکیشن‌های ساده تا متوسط مناسب‌اند (مثل داشبوردها، فرم‌ها یا اتوماسیون‌های ساده). برای سیستم‌های خیلی پیچیده هنوز به توسعه سنتی (Pro-code) نیاز داریم. به همین دلیل معمولاً این دو روش در کنار هم استفاده می‌شوند: Low-code برای سرعت، و Pro-code برای انعطاف و قدرت بیشتر.۱۶. سیستم‌های مدیریت فرآیند کسب‌وکار (BPMS)BPMS (مخفف Business Process Management Systems) یک نوع پلتفرم نرم‌افزاری است که کمک می‌کند فرآیندهای کاری یک سازمان را طراحی، اجرا، پایش و بهینه‌سازی کنیم. یعنی به جای اینکه کارها به‌صورت پراکنده و دستی انجام شوند، همه چیز به شکل یک جریان مشخص و قابل کنترل مدیریت می‌شود.در واقع BPM خودش «روش فکر کردن به فرآیندها» است، اما BPMS ابزار اجرایی آن است. این سیستم‌ها به سازمان کمک می‌کنند بفهمند کارها دقیقاً چطور انجام می‌شوند، کجاها گلوگاه وجود دارد و چطور می‌توان آن‌ها را بهتر کرد.BPMS معمولاً شامل طراحی فرآیند (Process Design)، اجرای گردش‌کار (Workflow Automation)، مانیتورینگ و تحلیل عملکرد است. بعضی نسخه‌های پیشرفته حتی اجازه می‌دهند فرآیندها قبل از اجرا شبیه‌سازی شوند تا مشکلات احتمالی دیده شود. مثلاً در یک شرکت، درخواست مرخصی، تأیید مدیر، ثبت در سیستم منابع انسانی و آرشیو شدن همه می‌تواند به صورت یک فرآیند در BPMS تعریف شود و سیستم خودش این مسیر را مدیریت کند.مزیت مهم BPMS این است که باعث شفافیت، کاهش کارهای تکراری، افزایش سرعت و کنترل بهتر روی فرآیندهای سازمانی می‌شود. در عین حال، چون همه چیز را ساختارمند می‌کند، سازمان راحت‌تر می‌تواند رشد کند و فرآیندها را توسعه دهد یا تغییر دهد.۱۷. Message QueueMessage Queue، یکی از ابزارهای مهم در معماری نرم‌افزارهای مدرن است که برای ارتباط غیرهم‌زمان بین بخش‌های مختلف سیستم استفاده می‌شود. ایده اصلی این است که به جای اینکه یک سرویس مستقیم منتظر پاسخ سرویس دیگر بماند، پیام‌ها را در یک صف قرار می‌دهد تا بعداً توسط سرویس‌های دیگر پردازش شوند.در این مدل، سه بخش اصلی داریم: فرستنده پیام (Producer) که کار یا درخواست را تولید می‌کند، صف پیام (Broker) که پیام‌ها را نگه‌داری و مدیریت می‌کند، و دریافت‌کننده (Consumer) که پیام‌ها را برداشته و پردازش می‌کند. ابزارهایی مثل Apache Kafka و RabbitMQ از معروف‌ترین نمونه‌ها هستند.به طور خلاصه، Message Queue مثل یک «ایستگاه پست دیجیتال» است که پیام‌ها را نگه می‌دارد تا هر سرویس در زمان مناسب آن‌ها را بردارد و پردازش کند، بدون اینکه همه چیز به هم وابسته باشد.۱۸. Containers and Container orchestrationکانتینرها یکی از مهم‌ترین فناوری‌های دنیای نرم‌افزار مدرن هستند که کمک می‌کنند برنامه‌ها همراه با تمام وابستگی‌هایشان (مثل کتابخانه‌ها و تنظیمات سیستم) در یک بسته‌ی مستقل اجرا شوند. این کار باعث می‌شود برنامه در هر سیستمی دقیقاً به یک شکل اجرا شود، بدون اینکه مشکل «روی سیستم من کار می‌کند ولی روی سیستم تو نه» پیش بیاید. Docker یکی از معروف‌ترین ابزارها برای ساخت و اجرای کانتینرها است. Docker به توسعه‌دهنده اجازه می‌دهد یک برنامه را داخل یک «ایمیج» بسته‌بندی کند و آن را روی هر سیستم اجرا کند.اما وقتی تعداد کانتینرها زیاد می‌شود (مثلاً صدها یا هزاران سرویس)، مدیریت آن‌ها سخت می‌شود. اینجاست که ابزارهایی مثل Kubernetes وارد می‌شوند. Kubernetes وظیفه دارد کانتینرها را در مقیاس بزرگ مدیریت کند، آن‌ها را بین سرورها پخش کند، در صورت خرابی دوباره اجرا کند و به صورت خودکار مقیاس (scale) سیستم را تنظیم کند.به زبان ساده:Docker = ساخت و اجرای کانتینرهاKubernetes = مدیریت و کنترل تعداد زیاد کانتینرها در یک سیستم بزرگبرای مثال، Docker مثل این است که یک «جعبه غذای آماده» درست کنیم، اما Kubernetes مثل سیستم مدیریت رستورانی است که هزاران سفارش را بین آشپزها تقسیم می‌کند، اگر یکی از آشپزها خراب شد جایگزین می‌آورد و در ساعات شلوغی تعداد آشپزها را زیاد می‌کند.در عمل، این دو معمولاً با هم استفاده می‌شوند: Docker برای ساخت و اجرای برنامه، و Kubernetes برای مدیریت آن در سطح بزرگ و حرفه‌ای.۱۹. معماری چندمستاجری (Multi-Tenancy Architecture)معماری Multi-Tenancy یا چندمستاجری به حالتی از طراحی نرم‌افزار گفته می‌شود که در آن یک نسخه (instance) از یک اپلیکیشن، به‌طور هم‌زمان به چندین مشتری یا گروه کاربری (tenant) سرویس می‌دهد. هر tenant می‌تواند یک فرد، یک شرکت یا یک سازمان باشد، اما نکته مهم این است که داده‌ها و تنظیمات هر کدام از هم جدا و ایزوله نگه داشته می‌شوند. فرض کنید یک مجتمع مسکونی بزرگ دارید. در این مجتمع، تمام ساکنین (مستاجرین) از یک زیرساخت مشترک (مثل اسکلت ساختمان، لوله‌کشی اصلی آب، آسانسور و ورودی مجتمع) استفاده می‌کنند، اما هر کدام واحد، کلید و حریم خصوصی کاملاً مستقل خود را دارند.در این معماری، همه کاربران از یک زیرساخت و یک اپلیکیشن مشترک استفاده می‌کنند، اما سیستم طوری طراحی شده که داده‌های هر tenant برای دیگران قابل مشاهده نیست. این موضوع هم باعث صرفه‌جویی در هزینه‌ها می‌شود و هم مدیریت سیستم را ساده‌تر می‌کند.اگر بخواهیم ساده بگوییم:در حالت Single-Tenant هر مشتری یک نسخه جدا از نرم‌افزار دارددر حالت Multi-Tenant همه مشتری‌ها روی یک نسخه مشترک هستند، اما از هم جدا نگه داشته می‌شوندمزیت مهم این مدل، کاهش هزینه، به‌روزرسانی ساده‌تر و مقیاس‌پذیری بهتر است. چون وقتی یک آپدیت داده می‌شود، برای همه مشتری‌ها هم‌زمان اعمال می‌شود.۲۰. مهاجرت داده‌ (Data Migration)Data Migration یا مهاجرت داده به فرآیند انتقال داده‌ها از یک سیستم به سیستم دیگر گفته می‌شود. این انتقال می‌تواند بین دیتابیس‌ها، نرم‌افزارها، سرورها، محیط‌های ابری یا حتی فرمت‌های مختلف فایل انجام شود. هدف اصلی این کار این است که داده‌ها به یک محیط جدید منتقل شوند بدون اینکه دقت، کامل بودن یا سازگاری آن‌ها از بین برود. وقتی یک سازمان تصمیم می‌گیرد سیستم‌های قدیمی خود را به‌روز کند، دیتابیس سنتی خود (مثلا SQL Server) را به ابر منتقل کند (مثلا روی Cloud)، یا دو شرکت با هم ادغام می‌شوند، نیاز به جابجایی داده‌ها دارند.در یک پروژه مهاجرت داده معمولاً سه مرحله اصلی داریم:اول انتخاب و آماده‌سازی داده‌ها (بررسی اینکه چه داده‌ای داریم و چه کیفیتی دارد)، دوم انتقال داده‌ها (جابجایی از سیستم قدیمی به جدید)، و سوم اعتبارسنجی (اطمینان از اینکه داده‌ها درست و کامل منتقل شده‌اند).چالش اصلی در Data Migration این است که داده‌ها معمولاً بسیار بزرگ، حساس و وابسته به سیستم‌های مختلف هستند. اگر کوچک‌ترین خطا در انتقال رخ دهد، ممکن است اطلاعات از بین برود یا سیستم جدید درست کار نکند.علی پاکدلعلی پاکدلMon, 01 Jun 2026 23:26:11 +0330https://virgool.ir/@aliipakdel98/مفاهیم-معماری-نرم-افزار-isogzagydmqj۱. مهندسی آشوب (Chaos Engineering)امروزه بسیاری از نرم‌افزارها و سرویس‌های آنلاین روی سیستم‌های پیچیده و توزیع‌شده اجرا می‌شوند. در چنین سیستم‌هایی ممکن است مشکلاتی مانند قطعی سرور، اختلال شبکه، افزایش ناگهانی کاربران یا خرابی بخشی از سیستم رخ دهد. مهندسی آشوب (Chaos Engineering) روشی است که به کمک آن این نوع خرابی‌ها به‌صورت عمدی و کنترل‌شده شبیه‌سازی می‌شوند تا مشخص شود سیستم در شرایط بحرانی چگونه عمل می‌کند.فرض کنید یک ماشین جدید ساخته‌اید. به جای اینکه منتظر بمانید تا در جاده و حین رانندگی تصادف کند، خودتان در پیست آزمایش با پتک به بدنه آن می‌کوبید یا ترمزها را دست‌کاری می‌کنید تا ببینید چقدر محکم است!مهندسی آشوب دقیقاً همین است. یعنی ما عمداً و در یک محیط کنترل‌شده، خرابکاری‌هایی (مثل قطع کردن یک سرور، شبیه‌سازی قطع اینترنت و یا پر کردن حافظه CPU) را وارد سیستم نرم‌افزاری خودمان می‌کنیم تا ببینیم آیا سیستم می‌تواند گلیم خودش را از آب بیرون بکشد و به کارش ادامه دهد یا کلاً منفجر می‌شود! هدف ما خرابکاری نیست، بلکه پیشگیری پیش‌دستانه (Proactive) از فاجعه است.به طور کلی، مهندسی آشوب به تیم‌های نرم‌افزاری کمک می‌کند تا قبل از وقوع بحران‌های واقعی، نقاط ضعف سیستم را شناسایی کرده و قابلیت اطمینان و تاب‌آوری نرم‌افزار را افزایش دهند.۲. بک‌اند برای فرانت‌اند (Backend for Frontend)Backend for Frontend یا به اختصار BFF یک الگوی معماری نرم‌افزار است که در آن برای هر نوع رابط کاربری یک بک‌اند اختصاصی در نظر گرفته می‌شود. ایده اصلی این است که نیازهای یک وب‌سایت، اپلیکیشن موبایل یا حتی یک دستگاه هوشمند با یکدیگر متفاوت هستند؛ بنابراین بهتر است هر کدام یک لایه بک‌اند مخصوص خود داشته باشند.در معماری‌های سنتی، همه فرانت‌اند‌ها مستقیماً با یک بک‌اند مشترک ارتباط برقرار می‌کنند. این موضوع باعث می‌شود بک‌اند مجبور باشد نیازهای مختلف و گاهی متناقض چندین نوع کاربر را پوشش دهد. در الگوی BFF، بین فرنت‌اند و سرویس‌های اصلی سیستم یک بک‌اند اختصاصی قرار می‌گیرد که فقط برای همان فرانت‌اند طراحی شده است.BFF یعنی ما به جای اینکه یک بک‌‌اند غول‌آسا داشته باشیم که سعی کند همه را راضی نگه دارد، برای هر کلاینت یک لایه بک‌‌اند اختصاصی و کوچک می‌سازیم. این لایه مانند یک «مترجم» عمل می‌کند که داده‌های خام را از میکروسرویس‌های اصلی می‌گیرد، آن‌ها را به شکلی که آن کلاینت خاص نیاز دارد فیلتر یا ترکیب می‌کند و تحویل می‌دهد.۳. هوش‌مصنوعی برای مهندسی نرم‌افزار (AI4SE)با پیچیده‌تر شدن سیستم‌های امروزی و کم شدن زمان عرضه به بازار، مهندسان نیاز به ابزارهای کمکی دارند. در اینجا اصطلاح AI4SE (مخفف AI for Systems Engineering) متولد می‌شود. به زبان ساده، در AI4SE از ابزارها و تکنیک‌های هوش مصنوعی (مثل یادگیری ماشین و پردازش داده‌ها) استفاده می‌شود تا فرآیند طراحی، ساخت، تست و نگهداری سیستم‌های پیچیده نرم‌افزاری را بهبود، سرعت و بهینه‌سازی ببخشد.در AI4SE از هوش مصنوعی برای انجام یا تسهیل کارهایی مانند تولید کد، یافتن خطاها، تولید تست، تحلیل نیازمندی‌ها و پیش‌بینی مشکلات احتمالی استفاده می‌شود. به این ترتیب، بخشی از کارهایی که قبلاً به‌صورت دستی انجام می‌شد، می‌تواند به کمک ابزارهای هوشمند سریع‌تر و دقیق‌تر انجام شود.۴. مهندسی‌ سیستم برای هوش‌مصنوعی (SE4AI)اگر در موضوع قبلی (AI4SE) از هوش مصنوعی به عنوان دستیار استفاده می‌کردیم، در SE4AI (مخفف Systems Engineering for AI) ورق کاملاً برمی‌گردد. در اینجا ما می‌خواهیم یک سیستم نرم‌افزاری بسازیم که خودش یک بخش هوش مصنوعی یا یادگیری ماشین در دلش دارد؛ مثلاً یک ماشین خودران، یک سیستم تشخیص پزشکی یا ابزار هوشمند بورس.سیستم‌های هوش مصنوعی معمولاً پیچیده‌تر از نرم‌افزارهای سنتی هستند؛ زیرا علاوه بر کد، شامل داده‌ها، مدل‌های یادگیری ماشین و فرآیندهای آموزش و به‌روزرسانی نیز می‌شوند. به همین دلیل، برای اطمینان از کیفیت، امنیت، قابلیت اطمینان و عملکرد صحیح این سیستم‌ها، باید از اصول مهندسی نرم‌افزار استفاده شود.تفاوت SE4AI با AI4SE در این است که در AI4SE، هوش مصنوعی به مهندسی نرم‌افزار کمک می‌کند؛ اما در SE4AI، مهندسی نرم‌افزار به ساخت و مدیریت سیستم‌های هوش مصنوعی کمک می‌کند.۵. عملیات یادگیری ماشین (MLOps)در دنیای مهندسی نرم‌افزار، ما سال‌هاست که از DevOps استفاده می‌کنیم تا فرآیند نوشتن کد و قرار دادن آن روی سرور را خودکار و سریع کنیم. اما وقتی پای یادگیری ماشین (Machine Learning) به میان می‌آید، قضیه خیلی پیچیده‌تر می‌شود؛ چون ما اینجا فقط با «کد» سروکار نداریم، بلکه با «کد + داده‌ها + مدل ریاضی» طرف هستیم.MLOps (مخفف Machine Learning Operations) مجموعه‌ای از روش‌ها و ابزارهاست که فرهنگ DevOps را وارد دنیای یادگیری ماشین می‌کند. هدف MLOps این است که چرخه حیات یک مدل هوش مصنوعی (از آماده‌سازی داده‌ها و آموزش مدل گرفته تا تست، ارزیابی، مستقر کردن روی سرور و پایش آن) را کاملاً خودکار و استاندارد کند تا مدل‌ها سریع‌تر و با خطای کمتر به دست کاربران برسند.در پروژه‌های یادگیری ماشین، تنها ساخت مدل کافی نیست. داده‌ها باید جمع‌آوری و آماده شوند، مدل آموزش ببیند، آزمایش شود، در محیط واقعی مستقر گردد و عملکرد آن به‌طور مداوم پایش شود. انجام دستی این مراحل زمان‌بر و پرخطا است. MLOps با استفاده از خودکارسازی، کنترل نسخه، CI/CD و پایش مداوم، این فرآیندها را ساده‌تر و قابل اعتمادتر می‌کند. از مهم‌ترین مزایای MLOps می‌توان به کاهش زمان استقرار مدل، افزایش همکاری بین تیم‌های داده و توسعه، بهبود کیفیت مدل‌ها و کاهش هزینه‌های نگهداری اشاره کرد.۶. زیرساخت به عنوان کد (IaC)Infrastructure as Code یا IaC روشی برای مدیریت و پیکربندی زیرساخت‌های فناوری اطلاعات از طریق کد است. در این رویکرد، به جای اینکه سرورها، شبکه‌ها، پایگاه‌های داده و سایر منابع به‌صورت دستی تنظیم شوند، تمام تنظیمات و مشخصات زیرساخت در قالب فایل‌های کد تعریف می‌شوند.IaC به زبان ساده‌تر می‌گوید که به جای کارهای دستی، بیایید کل ساختار زیرساخت (مثل سرورها، شبکه‌ها، لود بالانسرها و دیتابیس‌ها) را در قالب فایل‌های متنی و کد بنویسیم. ابزارهای IaC این کدها را می‌خوانند و خودکار در چند دقیقه دقیقاً همان محیطی که خواسته‌ایم را در کلود (مثل AWS یا سرورهای محلی) برای ما می‌سازند. با این کار، مدیریت زیرساخت دقیقاً مثل مدیریت کدهای یک نرم‌افزار می‌شود.مهم‌ترین مزیت IaC ایجاد یکپارچگی و تکرارپذیری است. وقتی زیرساخت از طریق کد تعریف شود، محیط‌های توسعه، تست و عملیاتی دقیقاً مشابه یکدیگر خواهند بود و مشکل «تفاوت محیط‌ها» به حداقل می‌رسد. همچنین استفاده از کنترل نسخه (Version Control) باعث می‌شود تغییرات زیرساخت قابل پیگیری و بازگشت باشند.۷. API Gateway & Service Meshدر معماری Microservices، دو فناوری مهم برای مدیریت ارتباطات وجود دارند: API Gateway و Service Mesh. این دو مفهوم گاهی شبیه به هم به نظر می‌رسند، اما وظایف متفاوتی دارند و معمولاً در کنار یکدیگر استفاده می‌شوند. وقتی یک معماری یکپارچه (Monolith) را می‌شکنیم و به کلی میکروسرویس کوچک تبدیل می‌شود، دو چالش بزرگ ارتباطی داریم:۱. کلاینت‌های بیرونی (مثل اپلیکیشن موبایل کاربر) چطور باید با این همه سرویس داخلی صحبت کنند؟۲. این میکروسرویس‌های داخلی چطور خودشان با یکدیگر امن و سریع ارتباط برقرار کنند؟برای حل این دو چالش، دو تکنولوژی متفاوت اما مکمل داریم: API Gateway و Service Mesh.API Gateway در ورودی سیستم قرار می‌گیرد و تمام درخواست‌های کاربران یا سیستم‌های خارجی را دریافت می‌کند. این لایه وظایفی مانند مسیریابی درخواست‌ها، احراز هویت، محدودسازی تعداد درخواست‌ها (Rate Limiting)، مدیریت نسخه‌های API و نظارت بر ترافیک را انجام می‌دهد. به بیان ساده، API Gateway دروازه ورود به سیستم است.در مقابل، Service Mesh برای مدیریت ارتباط بین سرویس‌های داخلی یک معماری میکروسرویسی استفاده می‌شود. این فناوری ارتباط سرویس‌ها با یکدیگر را کنترل می‌کند و قابلیت‌هایی مانند کشف سرویس‌ها، توازن بار (Load Balancing)، رمزنگاری ارتباطات، مانیتورینگ و مدیریت خطاها را فراهم می‌کند.۸. تفکیک مسئولیت دستور و پرس‌وجو (CQRS)CQRS (مخفف Command Query Responsibility Segregation) یا تفکیک مسئولیت فرمان و پرس‌وجو یک الگوی معماری نرم‌افزار است که عملیات خواندن اطلاعات (Query) را از عملیات نوشتن و تغییر اطلاعات (Command) جدا می‌کند. در این الگو، به جای استفاده از یک مدل مشترک برای خواندن و نوشتن داده‌ها، برای هر کدام مدل یا حتی پایگاه داده جداگانه در نظر گرفته می‌شود.در معماری‌های سنتی (CRUD)، یک مدل واحد هم برای خواندن و هم برای تغییر داده‌ها استفاده می‌شود. اما در سیستم‌های پیچیده، نیازهای بخش خواندن و نوشتن معمولاً متفاوت هستند. برای مثال، در یک فروشگاه اینترنتی، ممکن است ثبت سفارش (نوشتن) نیاز به پردازش تراکنش سنگین داشته باشد، اما کاربران هم‌زمان هزاران بار لیست محصولات (خواندن) را لود کنند. استفاده از یک مدل برای هر دو کار، کارایی سیستم را پایین می‌آورد.مزیت اصلی CQRS افزایش کارایی، مقیاس‌پذیری و انعطاف‌پذیری سیستم است. با این حال، پیاده‌سازی آن پیچیدگی بیشتری نسبت به معماری‌های معمولی دارد و معمولاً برای سیستم‌های بزرگ و پیچیده توصیه می‌شود.۹.معماری رویداد-محور (EDA)EDA (مخفف Event-Driven Architecture) یا معماری رویدادمحور یک الگوی معماری نرم‌افزار است که در آن اجزای سیستم از طریق رویدادها (Events) با یکدیگر ارتباط برقرار می‌کنند. رویداد به هر اتفاق مهمی در سیستم گفته می‌شود؛ مانند ثبت سفارش، پرداخت موفق، ورود کاربر یا تغییر وضعیت یک محصول.در معماری‌های سنتی، سیستم‌ها به صورت هم‌گام (Synchronous) با هم صحبت می‌کنند؛ یعنی سیستم A به سیستم B زنگ می‌زند و منتظر می‌ماند تا جواب را بگیرد. اگر سیستم B قطع باشد، کار سیستم A هم لنگ می‌ماند.اما معماری رویداد-محور (EDA) می‌گوید: سیستم‌ها باید به صورت ناهم‌گام (Asynchronous) و بر پایه رویدادها با هم ارتباط داشته باشند. رویداد یعنی «یک اتفاق مهم که در سیستم رخ داده و تمام شده است»؛ مثلاً: «کاربر دکمه خرید را زد»، «دمای سنسور به ۱۸۰ درجه رسید» یا «پرداخت موفقیت‌آمیز بود».در این معماری، فرستنده (Producer) رویداد کاری ندارد که چه کسی قرار است این پیام را بگیرد؛ او فقط رویداد را داخل یک تالار گفتگو ارسال می‌کند. گیرندگان رویداد (Consumers) که گوش‌به‌زنگ نشسته‌اند، هر زمان که آمادگی داشتند این پیام را برمی‌دارند و کار خودشان را انجام می‌دهند. فرستنده و گیرنده اصلاً همدیگر را نمی‌شناسند.۱۰. معماری بدون سرور (Serverless Architecture)Serverless Architecture یک سبک معماری است که در آن توسعه‌دهندگان بدون مدیریت مستقیم سرورها، برنامه‌های خود را توسعه و اجرا می‌کنند. در این مدل، تأمین، نگهداری، مقیاس‌پذیری و مدیریت زیرساخت بر عهده ارائه‌دهنده خدمات ابری است و توسعه‌دهندگان تنها روی منطق و کدنویسی برنامه تمرکز می‌کنند.بزرگ‌ترین اشتباه در کلمه Serverless این است که فکر کنیم «هیچ سروری در کار نیست!». در واقع، سرورها وجود دارند، اما دلیل این نام‌گذاری این است که شما به عنوان یک توسعه‌دهنده یا معمار نرم‌افزار، هیچ نیازی به دیدن، مدیریت، آپدیت یا خرید سرورها ندارید. در معماری سنتی، شما باید یک سرور مجازی اجاره می‌کردید، سیستم‌عاملش را آپدیت می‌کردید و نگران می‌شدید که اگر ترافیک بالا رفت سرور کرش نکند. اما در معماری بدون سرور، کل این دردسرها به عهده شرکت ارائه‌دهنده خدمات ابری (مثل آمازون، گوگل یا مایکروسافت) است. شما فقط کد خود را می‌نویسید و آپلود می‌کنید؛ سیستم ابری خودش به ازای هر درخواستی که سمت برنامه می‌آید، موقتاً یک سرور روشن می‌کند، کد شما را اجرا می‌کند، جواب کاربر را می‌دهد و بعد سرور را خاموش می‌کند!مزایای اصلی Serverless شامل کاهش پیچیدگی مدیریت زیرساخت، افزایش سرعت توسعه، مقیاس‌پذیری خودکار و کاهش هزینه‌های عملیاتی است. با این حال، چالش‌هایی مانند وابستگی به ارائه‌دهنده سرویس، محدودیت منابع و تأخیر اولیه اجرای سرویس‌ها (Cold Start) نیز وجود دارد.۱۱. API-First ApproachAPI-First یک رویکرد توسعه نرم‌افزار است که در آن طراحی و تعریف APIها پیش از پیاده‌سازی سایر بخش‌های سیستم انجام می‌شود. در این رویکرد، APIها به‌عنوان اجزای اصلی و پایه‌ای سیستم در نظر گرفته می‌شوند و سایر بخش‌ها مانند وب‌سایت، اپلیکیشن موبایل یا سرویس‌های دیگر بر اساس آن‌ها توسعه می‌یابند.در روش‌های سنتی، وقتی می‌خواستیم یک نرم‌افزار بسازیم، اول دیتابیس و کدهای بک‌اند را می‌نوشتیم، ظاهر برنامه را طراحی می‌کردیم و در آخر به سراغ APIها می‌رفتیم.اما رویکرد API-First دقیقاً برعکس است . این رویکرد می‌گوید: قبل از اینکه حتی یک خط کد برای برنامه بنویسید، اول باید روی طراحی، مستندسازی و ساختار مشخص API توافق کنید. در این مدل، API به عنوان یک «شهروند درجه یک» و پایه و اساس کل پروژه در نظر گرفته می‌شود. ما ابتدا یک «قرارداد» (Contract) با ابزارهایی مثل OpenAPI/Swagger می‌سازیم که می‌گوید سیستم قرار است چه ورودی و خروجی‌هایی داشته باشد، سپس همه تیم‌ها کارشان را بر اساس این قرارداد شروع می‌کنند.مزایای اصلی این رویکرد شامل توسعه سریع‌تر، قابلیت استفاده مجدد از سرویس‌ها، یکپارچگی بهتر بین سیستم‌ها، بهبود تجربه توسعه‌دهندگان و پشتیبانی مناسب از معماری‌های مدرن مانند میکروسرویس‌ها است. به همین دلیل API-First به یکی از رویکردهای رایج در توسعه سامانه‌های مدرن تبدیل شده است.۱۲. طراحی دامنه‌محور (Domain-Driven Design)Domain-Driven Design یا DDD یک رویکرد طراحی نرم‌افزار است که تمرکز اصلی آن بر درک عمیق حوزه کسب‌وکار (Domain) و مدل‌سازی نرم‌افزار بر اساس مفاهیم و قوانین آن حوزه است. در این رویکرد، توسعه‌دهندگان و متخصصان کسب‌وکار با استفاده از یک زبان مشترک (Ubiquitous Language) همکاری می‌کنند تا نرم‌افزار بیشترین تطابق را با نیازهای واقعی سازمان داشته باشد.بسیاری از پروژه‌های نرم‌افزاری به این دلیل شکست می‌خورند که برنامه‌نویسان بهترین تکنولوژی‌ها را استفاده کرده‌اند، اما دقیقاً نفهمیده‌اند که بیزینس یا همان دامنه کارفرما چطور کار می‌کند! به عنوان مثال شما نمی‌توانید یک سیستم بانکی عالی بسازید، مگر اینکه اول محاسبات پیچیده بانکی و قوانین آن را عمیقاً درک کنید.DDD می‌گوید که قلب فرآیند توسعه باید مدل‌سازی دقیق فرآیندها، قوانین و نیازمند‌ی‌های بیزینس باشد، نه مسائل فنی و دیتابیس. در این روش، برنامه‌نویسان و متخصصان بیزینس کنار هم می‌نشینند و یک زبان مشترک خلق می‌کنند. یعنی کلماتی که در کد استفاده می‌شود (مثل نام متغیرها و کلاس‌ها) باید دقیقاً همان کلماتی باشد که کارفرما در دنیای واقعی استفاده می‌کند.۱۳. معماری شش‌ضلعی (Hexagonal Architecture)معماری شش‌ضلعی یا Hexagonal Architecture یک روش طراحی نرم‌افزار است که هدفش جدا کردن منطق اصلی برنامه (Business Logic) از جزئیات فنی مثل دیتابیس، رابط کاربری و سرویس‌های بیرونی است. در این مدل، هسته‌ی برنامه در مرکز قرار دارد و همه چیز از طریق «پورت‌ها» و «آداپتورها» به آن وصل می‌شود.در معماری‌های سنتی (۳ لایه)، لایه بیزینس مستقیماً به لایه دیتابیس وصل است. این یعنی اگر بخواهید دیتابیس را عوض کنید یا پکیج جدیدی نص کنید، احتمالاً کدهای اصلی بیزینس شما دستخوش تغییر و باگ می‌شوند.اما معماری شش‌ضلعی می‌گوید: هسته اصلی برنامه باید مثل یک جزیره کاملاً مستقل در مرکز قرار بگیرد و هیچ ابزار خارجی (مثل دیتابیس، پنل وب، تلگرام بوت، یا APIهای دیگر) نباید به درون آن نفوذ کنند. هسته برنامه فقط تعدادی پورت (که در کد همان Interfaceها یا قراردادها هستند) معرفی می‌کند. ابزارهای بیرونی، آداپتور مخصوص خود را می‌نویسند تا به این پورت‌ها وصل شوند؛ درست مثل لپ‌تاپ شما که یک پورت USB (مستقل از تکنولوژی) دارد و شما می‌توانید هم موس، هم کیبورد و هم هارد اکسترنال را با آداپتورهایشان به آن وصل کنید، بدون اینکه ساختار داخلی لپ‌تاپ تغییر کند.۱۴. Event SourcingEvent Sourcing یک سبک معماری است که به جای اینکه فقط «وضعیت فعلی» سیستم را ذخیره کنیم، تمام تغییراتی که روی سیستم اتفاق می‌افتد را به شکل «رویداد» ذخیره می‌کند. یعنی به جای اینکه فقط بدانیم الان وضعیت چیست، دقیقاً می‌دانیم چه اتفاق‌هایی افتاده که ما را به این وضعیت رسانده است.در دیتابیس‌های سنتی (CRUD)، ما همیشه آخرین وضعیت یک داده را ذخیره می‌کنیم. مثلاً اگر موجودی حساب شما ۱۰۰ هزار تومان باشد و ۵۰ هزار تومان واریز کنید، عدد ۱۰۰ به ۱۵۰ تبدیل می‌شود. اگر کسی بپرسد «این ۱۵۰ هزار تومان چطور به دست آمده؟»، دیتابیس سنتی چیزی برای گفتن ندارد، مگر اینکه یک سیستم لاگ‌گیری جداگانه ساخته باشید.الگوی Event Sourcing می‌گوید: ما اصلاً وضعیت فعلی را ذخیره نمی‌کنیم؛ بلکه تمام اتفاقات و رویدادهایی که منجر به این وضعیت شده‌اند را به صورت یک زنجیره متوالی ذخیره می‌کنیم. در این معماری، دیتابیس ما یک بانک اطلاعاتی فقط‌افزودنی (Append-only) به نام Event Store است. برای به دست آوردن موجودی فعلی حساب، سیستم از نقطه صفر شروع می‌کند و تمام رویدادهای واریز و برداشت را از ابتدا تا انتها روی حساب بازیانی (Replay) می‌کند تا به عدد نهایی برسد. سیستم کنترل نسخه (مثل Git) یا دفتر کل حسابداری بهترین مثال‌های ملموس برای این الگو هستند؛ گیت کدهای نهایی را ذخیره نمی‌کند، بلکه تغییرات را نگه می‌دارد.مزیت مهم این روش این است که علاوه بر وضعیت فعلی، تاریخچه کامل هم داریم. بنابراین می‌توانیم بفهمیم چه زمانی چه اتفاقی افتاده، یا حتی وضعیت سیستم را در یک زمان خاص بازسازی کنیم. البته در عوض، طراحی و پیاده‌سازی آن پیچیده‌تر و سنگین‌تر از روش‌های سنتی است.۱۵. پلتفرم‌های Low-code/No-codeپلتفرم‌های Low-code و No-code ابزارهایی هستند که ساخت نرم‌افزار را خیلی ساده‌تر و سریع‌تر می‌کنند، طوری که لازم نیست مثل روش‌های سنتی همه‌چیز را خط‌به‌خط کدنویسی کنیم.این پلتفرم‌ها به کمک واسط‌های کاربری گرافیکی، ابزارهای کشیدن و رها کردن (Drag-and-Drop) و مدل‌سازی بصری به کاربران اجازه می‌دهند بدون درگیر شدن با پیچیدگی‌های کدنویسی، برنامه بسازند:No-Code: مخصوص افرادی است که اصلاً دانش برنامه‌نویسی ندارند. آن‌ها به کمک ابزارهای کاملاً بصری، کارهای خود را جلو می‌برند.Low-Code: به کمی دانش پایه برنامه‌نویسی نیاز دارد و به توسعه‌دهندگان حرفه‌ای کمک می‌کند تا کارهای تکراری (مثل ساخت فرم‌ها یا اتصال به دیتابیس) را با سرعت بالا (تا ۹۰٪ سریع‌تر) انجام دهند و فقط بخش‌های بسیار خاص را کدنویسی کنند.البته این ابزارها بیشتر برای اپلیکیشن‌های ساده تا متوسط مناسب‌اند (مثل داشبوردها، فرم‌ها یا اتوماسیون‌های ساده). برای سیستم‌های خیلی پیچیده هنوز به توسعه سنتی (Pro-code) نیاز داریم. به همین دلیل معمولاً این دو روش در کنار هم استفاده می‌شوند: Low-code برای سرعت، و Pro-code برای انعطاف و قدرت بیشتر.۱۶. سیستم‌های مدیریت فرآیند کسب‌وکار (BPMS)BPMS (مخفف Business Process Management Systems) یک نوع پلتفرم نرم‌افزاری است که کمک می‌کند فرآیندهای کاری یک سازمان را طراحی، اجرا، پایش و بهینه‌سازی کنیم. یعنی به جای اینکه کارها به‌صورت پراکنده و دستی انجام شوند، همه چیز به شکل یک جریان مشخص و قابل کنترل مدیریت می‌شود.در واقع BPM خودش «روش فکر کردن به فرآیندها» است، اما BPMS ابزار اجرایی آن است. این سیستم‌ها به سازمان کمک می‌کنند بفهمند کارها دقیقاً چطور انجام می‌شوند، کجاها گلوگاه وجود دارد و چطور می‌توان آن‌ها را بهتر کرد.BPMS معمولاً شامل طراحی فرآیند (Process Design)، اجرای گردش‌کار (Workflow Automation)، مانیتورینگ و تحلیل عملکرد است. بعضی نسخه‌های پیشرفته حتی اجازه می‌دهند فرآیندها قبل از اجرا شبیه‌سازی شوند تا مشکلات احتمالی دیده شود. مثلاً در یک شرکت، درخواست مرخصی، تأیید مدیر، ثبت در سیستم منابع انسانی و آرشیو شدن همه می‌تواند به صورت یک فرآیند در BPMS تعریف شود و سیستم خودش این مسیر را مدیریت کند.مزیت مهم BPMS این است که باعث شفافیت، کاهش کارهای تکراری، افزایش سرعت و کنترل بهتر روی فرآیندهای سازمانی می‌شود. در عین حال، چون همه چیز را ساختارمند می‌کند، سازمان راحت‌تر می‌تواند رشد کند و فرآیندها را توسعه دهد یا تغییر دهد.۱۷. Message QueueMessage Queue، یکی از ابزارهای مهم در معماری نرم‌افزارهای مدرن است که برای ارتباط غیرهم‌زمان بین بخش‌های مختلف سیستم استفاده می‌شود. ایده اصلی این است که به جای اینکه یک سرویس مستقیم منتظر پاسخ سرویس دیگر بماند، پیام‌ها را در یک صف قرار می‌دهد تا بعداً توسط سرویس‌های دیگر پردازش شوند.در این مدل، سه بخش اصلی داریم: فرستنده پیام (Producer) که کار یا درخواست را تولید می‌کند، صف پیام (Broker) که پیام‌ها را نگه‌داری و مدیریت می‌کند، و دریافت‌کننده (Consumer) که پیام‌ها را برداشته و پردازش می‌کند. ابزارهایی مثل Apache Kafka و RabbitMQ از معروف‌ترین نمونه‌ها هستند.به طور خلاصه، Message Queue مثل یک «ایستگاه پست دیجیتال» است که پیام‌ها را نگه می‌دارد تا هر سرویس در زمان مناسب آن‌ها را بردارد و پردازش کند، بدون اینکه همه چیز به هم وابسته باشد.۱۸. Containers and Container orchestrationکانتینرها یکی از مهم‌ترین فناوری‌های دنیای نرم‌افزار مدرن هستند که کمک می‌کنند برنامه‌ها همراه با تمام وابستگی‌هایشان (مثل کتابخانه‌ها و تنظیمات سیستم) در یک بسته‌ی مستقل اجرا شوند. این کار باعث می‌شود برنامه در هر سیستمی دقیقاً به یک شکل اجرا شود، بدون اینکه مشکل «روی سیستم من کار می‌کند ولی روی سیستم تو نه» پیش بیاید. Docker یکی از معروف‌ترین ابزارها برای ساخت و اجرای کانتینرها است. Docker به توسعه‌دهنده اجازه می‌دهد یک برنامه را داخل یک «ایمیج» بسته‌بندی کند و آن را روی هر سیستم اجرا کند.اما وقتی تعداد کانتینرها زیاد می‌شود (مثلاً صدها یا هزاران سرویس)، مدیریت آن‌ها سخت می‌شود. اینجاست که ابزارهایی مثل Kubernetes وارد می‌شوند. Kubernetes وظیفه دارد کانتینرها را در مقیاس بزرگ مدیریت کند، آن‌ها را بین سرورها پخش کند، در صورت خرابی دوباره اجرا کند و به صورت خودکار مقیاس (scale) سیستم را تنظیم کند.به زبان ساده:Docker = ساخت و اجرای کانتینرهاKubernetes = مدیریت و کنترل تعداد زیاد کانتینرها در یک سیستم بزرگبرای مثال، Docker مثل این است که یک «جعبه غذای آماده» درست کنیم، اما Kubernetes مثل سیستم مدیریت رستورانی است که هزاران سفارش را بین آشپزها تقسیم می‌کند، اگر یکی از آشپزها خراب شد جایگزین می‌آورد و در ساعات شلوغی تعداد آشپزها را زیاد می‌کند.در عمل، این دو معمولاً با هم استفاده می‌شوند: Docker برای ساخت و اجرای برنامه، و Kubernetes برای مدیریت آن در سطح بزرگ و حرفه‌ای.۱۹. معماری چندمستاجری (Multi-Tenancy Architecture)معماری Multi-Tenancy یا چندمستاجری به حالتی از طراحی نرم‌افزار گفته می‌شود که در آن یک نسخه (instance) از یک اپلیکیشن، به‌طور هم‌زمان به چندین مشتری یا گروه کاربری (tenant) سرویس می‌دهد. هر tenant می‌تواند یک فرد، یک شرکت یا یک سازمان باشد، اما نکته مهم این است که داده‌ها و تنظیمات هر کدام از هم جدا و ایزوله نگه داشته می‌شوند. فرض کنید یک مجتمع مسکونی بزرگ دارید. در این مجتمع، تمام ساکنین (مستاجرین) از یک زیرساخت مشترک (مثل اسکلت ساختمان، لوله‌کشی اصلی آب، آسانسور و ورودی مجتمع) استفاده می‌کنند، اما هر کدام واحد، کلید و حریم خصوصی کاملاً مستقل خود را دارند.در این معماری، همه کاربران از یک زیرساخت و یک اپلیکیشن مشترک استفاده می‌کنند، اما سیستم طوری طراحی شده که داده‌های هر tenant برای دیگران قابل مشاهده نیست. این موضوع هم باعث صرفه‌جویی در هزینه‌ها می‌شود و هم مدیریت سیستم را ساده‌تر می‌کند.اگر بخواهیم ساده بگوییم:در حالت Single-Tenant هر مشتری یک نسخه جدا از نرم‌افزار دارددر حالت Multi-Tenant همه مشتری‌ها روی یک نسخه مشترک هستند، اما از هم جدا نگه داشته می‌شوندمزیت مهم این مدل، کاهش هزینه، به‌روزرسانی ساده‌تر و مقیاس‌پذیری بهتر است. چون وقتی یک آپدیت داده می‌شود، برای همه مشتری‌ها هم‌زمان اعمال می‌شود.۲۰. مهاجرت داده‌ (Data Migration)Data Migration یا مهاجرت داده به فرآیند انتقال داده‌ها از یک سیستم به سیستم دیگر گفته می‌شود. این انتقال می‌تواند بین دیتابیس‌ها، نرم‌افزارها، سرورها، محیط‌های ابری یا حتی فرمت‌های مختلف فایل انجام شود. هدف اصلی این کار این است که داده‌ها به یک محیط جدید منتقل شوند بدون اینکه دقت، کامل بودن یا سازگاری آن‌ها از بین برود. وقتی یک سازمان تصمیم می‌گیرد سیستم‌های قدیمی خود را به‌روز کند، دیتابیس سنتی خود (مثلا SQL Server) را به ابر منتقل کند (مثلا روی Cloud)، یا دو شرکت با هم ادغام می‌شوند، نیاز به جابجایی داده‌ها دارند.در یک پروژه مهاجرت داده معمولاً سه مرحله اصلی داریم:اول انتخاب و آماده‌سازی داده‌ها (بررسی اینکه چه داده‌ای داریم و چه کیفیتی دارد)، دوم انتقال داده‌ها (جابجایی از سیستم قدیمی به جدید)، و سوم اعتبارسنجی (اطمینان از اینکه داده‌ها درست و کامل منتقل شده‌اند).چالش اصلی در Data Migration این است که داده‌ها معمولاً بسیار بزرگ، حساس و وابسته به سیستم‌های مختلف هستند. اگر کوچک‌ترین خطا در انتقال رخ دهد، ممکن است اطلاعات از بین برود یا سیستم جدید درست کار نکند.علی پاکدلعلی پاکدلMon, 01 Jun 2026 23:20:49 +0330