https://virgool.ir/feed/@m_12585742fa2026-11-10 18:47:57https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@m_12585742https://virgool.ir/@m_12585742/کتاب-team-topology-از-دید-من-jhf34ckcnddcTeam Topologies چیست و چرا ساختار تیم‌ها روی معماری نرم‌افزار اثر می‌گذارد؟در سازمان‌های فناوری، نرم‌افزار را نمی‌توان جدا از افرادی که آن را طراحی، توسعه و نگهداری می‌کنند بررسی کرد. سیستم‌های نرم‌افزاری امروز پیچیده‌اند و توسعه آن‌ها به همکاری تخصص‌های مختلف نیاز دارد. در چنین محیطی، سرعت تحویل و کیفیت دو هدف جدا از هم نیستند و سازمان باید بتواند هر دو را هم‌زمان حفظ کند.مشکل اینجاست که بسیاری از سازمان‌ها هنوز برای تقسیم کار و طراحی تیم‌ها به چارت‌های سازمانی سنتی تکیه می‌کنند. این چارت‌ها بیشتر برای مشخص کردن سلسله‌مراتب، مسئولیت‌های رسمی و زنجیره گزارش‌دهی مناسب‌اند، اما لزوما نشان نمی‌دهند که کار در واقعیت چگونه در سازمان حرکت می‌کند. افراد و تیم‌ها برای انجام کار، معمولاً خارج از خطوط رسمی چارت با یکدیگر ارتباط برقرار می‌کنند و شبکه‌ای از روابط شکل می‌گیرد که با ساختار رسمی سازمان تفاوت دارد.اگر یک تیم بتواند بخش خودش از کار را در چند ساعت انجام دهد اما برای ادامه مسیر مجبور باشد تا جلسه هفتگی مدیران منتظر بماند، بهینه شدن آن تیم تأثیر چندانی روی سرعت کل سیستم ندارد. مسئله اصلی جریان کامل کار است، نه عملکرد یک واحد به صورت جداگانه.به همین دلیل، Team Topologies از سازمان به عنوان مجموعه‌ای ثابت از واحدها و دپارتمان‌ها نگاه نمی‌کند. تمرکز اصلی روی تیم‌ها، مرز مسئولیت آن‌ها و نحوه تعاملشان با یکدیگر است. ساختار تیمی باید به صورت آگاهانه طراحی شود و متناسب با اندازه سازمان، بلوغ مهندسی، معماری نرم‌افزار و شرایط کسب‌وکار تغییر کند. ساختارهایی که با این نگاه طراحی می‌شوند، توپولوژی‌های تیمی یا Team Topologies نام دارند.چارت سازمانی، ساختار واقعی سازمان را نشان نمی‌دهدیک سازمان در عمل فقط یک ساختار ندارد بلکه سه ساختار هم‌زمان برای سازمان در نظر گرفته شده است:ساختار رسمی که همان چارت سازمانی و زنجیره گزارش‌دهی است.ساختار غیررسمی که روابط و میزان نفوذ افراد روی یکدیگر را نشان می‌دهد.ساختار خلق ارزش که مشخص می‌کند کار در واقعیت چگونه بین افراد و تیم‌ها پیش می‌رود.برای توسعه نرم‌افزار، دو مورد دوم اهمیت زیادی دارند. ممکن است روی چارت سازمانی دو تیم کاملا جدا از هم باشند، اما در عمل هر روز برای انجام کار به یکدیگر وابسته باشند. برعکس، ممکن است دو واحد در ساختار رسمی نزدیک به هم باشند ولی جریان کاری مستقلی داشته باشند.این وابستگی‌های واقعی روی سرعت تحویل نرم‌افزار اثر مستقیم دارند. اگر هر تغییر نیازمند هماهنگی چند تیم، تأیید چند مدیر یا عبور از چند واحد تخصصی باشد، جریان کار کند می‌شود. در چنین شرایطی، افزایش سرعت یک تیم به تنهایی مسئله را حل نمی‌کند.Team Topologies تلاش می‌کند این روابط را به شکل آگاهانه طراحی کند. هدف این نیست که همه تیم‌ها دائما با هم در ارتباط باشند. در بسیاری از موارد، ارتباط کمتر و مرزهای شفاف‌تر نتیجه بهتری ایجاد می‌کند.قانون کانوی: معماری نرم‌افزار از ساختار ارتباطی سازمان جدا نیستیکی از پایه‌های اصلی Team Topologies، قانون کانوی یا Conway's Law است. ایده آن این است که ساختار سیستم‌هایی که یک سازمان طراحی می‌کند، به الگوهای ارتباطی همان سازمان شباهت پیدا می‌کند.اگر چهار تیم جداگانه روی یک سیستم کار کنند، احتمال زیادی وجود دارد که ساختار نهایی سیستم نیز به چهار بخش مجزا تقسیم شود. اگر توسعه‌دهندگان برای هر تغییر در دیتابیس مجبور باشند از یک تیم مرکزی DBA کمک بگیرند، این وابستگی نیز به شکلی در معماری نرم‌افزار دیده خواهد شد.این موضوع زمانی مشکل‌ساز می‌شود که معماری مورد نظر با ساختار واقعی تیم‌ها همخوانی نداشته باشد. ممکن است روی کاغذ یک معماری مستقل و ماژولار طراحی شود، اما اگر تیم‌ها برای انجام هر تغییر دائما به یکدیگر وابسته باشند، سیستم نهایی هم استقلال مورد انتظار را نخواهد داشت.در شرکت آدیداس، ساختار فناوری اطلاعات شرکت بر اساس همین نگاه تغییر کرد. ۸۰ درصد مهندسان در تیم‌های چندتخصصی متمرکز بر نیازهای محصول قرار گرفتند و ۲۰ درصد باقی‌مانده در یک تیم مرکزی روی زیرساخت و آموزش نیروهای جدید کار کردند. پس از این تغییر سرعت انتشار محصولات دیجیتال آدیداس ۶۰ برابر شد.حرکت معکوس کانویاگر معماری نرم‌افزار از ساختار ارتباطی سازمان تأثیر می‌گیرد، می‌توان این رابطه را به صورت آگاهانه در جهت عکس استفاده کرد. این رویکرد Reverse Conway Maneuver نام دارد.در این روش، ابتدا معماری‌ای را که برای سیستم مناسب است مشخص می‌کنیم و سپس ساختار تیم‌ها را طوری طراحی می‌کنیم که با آن معماری هم‌راستا باشد.فرض کنید چهار تیم توسعه وجود دارند، اما همه آن‌ها برای تغییر دیتابیس به یک تیم مرکزی DBA وابسته‌اند. خروجی طبیعی چنین ساختاری، سیستم‌هایی است که به یک پایگاه داده مشترک وابستگی زیادی دارند.اگر هدف استفاده از معماری‌ای باشد که در آن هر بخش سیستم پایگاه داده مستقل خود را داشته باشد، ساختار قبلی با این هدف سازگار نیست. در این حالت می‌توان تخصص دیتابیس را به داخل تیم‌های توسعه منتقل کرد تا هر تیم بتواند بخش خودش را مستقل‌تر مدیریت کند.بنابراین معماری فقط یک تصمیم فنی نیست. تصمیم درباره اینکه چه کسی با چه کسی کار می‌کند، هر تیم مسئول چه چیزی است و چه وابستگی‌هایی میان تیم‌ها وجود دارد، عملاً بخشی از طراحی معماری سیستم است.ارتباط بیشتر همیشه بهتر نیستیکی از نتایجی که از قانون کانوی گرفته می‌شود این است که افزایش ارتباط میان تیم‌ها همیشه نتیجه مثبتی ندارد.اگر دو تیم از نظر معماری سیستم نباید وابستگی زیادی به یکدیگر داشته باشند، اما برای انجام کار روزانه دائما مجبور به هماهنگی هستند، احتمالا مشکلی در مرزهای سیستم یا مسئولیت تیم‌ها وجود دارد. شاید APIها مناسب نیستند، زیرساخت کافی وجود ندارد یا بخشی از مسئولیت میان دو تیم به درستی تقسیم نشده است.هدف این است که تیم‌ها بتوانند بخش زیادی از کار خود را بدون هماهنگی دائمی با دیگران انجام دهند. ارتباط بین تیم‌ها باید هدفمند باشد، نه اینکه همه برای هر تصمیمی با همه در تماس باشند.ابزارهایی که تیم‌ها استفاده می‌کنند نیز روی این روابط اثر می‌گذارند. اگر دو تیم باید همکاری نزدیکی داشته باشند، ابزارهای مشترک می‌توانند این همکاری را ساده‌تر کنند. اگر دو تیم باید مستقل باشند، تحمیل یک ابزار مشترک ممکن است مرز مسئولیت آن‌ها را مبهم کند.تیم باید واحد اصلی انجام کار باشدیکی دیگر از اصول Team Topologies این است که به جای فرد، تیم را واحد اصلی انجام کار در نظر بگیریم.در این نگاه، یک تیم گروهی پایدار و نسبتا کوچک از افراد است که برای رسیدن به یک هدف مشترک کار می‌کنند. کار به تیم سپرده می‌شود، نه اینکه افراد دائما بین پروژه‌ها و گروه‌های مختلف جابه‌جا شوند.تیم برای رسیدن به هماهنگی و اعتماد به زمان نیاز دارد. تشکیل یک گروه برای یک پروژه چندماهه و متلاشی کردن آن پس از پایان پروژه باعث می‌شود سازمان بارها هزینه شکل‌گیری دوباره تیم را بپردازد. اندازه تیم، معمولا محدوده پنج تا نه نفر را مطرح می‌کند. بزرگ شدن بیش از حد تیم، تعداد مسیرهای ارتباطی را افزایش می‌دهد و حفظ اعتماد و درک مشترک را دشوارتر می‌کند.تیم‌های پایدار این امکان را دارند که به مرور روش کار مشترک ایجاد کنند، دانش خود را درباره سیستم افزایش دهند و مسئولیت واقعی نرم‌افزاری را که توسعه می‌دهند بر عهده بگیرند.مالکیت نرم‌افزار باید متعلق به تیم باشددر ساختار تیم‌محور، هر بخش نرم‌افزار باید مالک مشخصی داشته باشد و این مالک یک تیم است.اگر چند تیم بتوانند بدون مرز مشخص یک بخش از سیستم را تغییر دهند، مسئولیت مشکلات ایجادشده نیز مبهم می‌شود. در مقابل، وقتی یک تیم مالک یک سیستم یا زیرسیستم مشخص است، اثر تصمیم‌های خود را در طول زمان می‌بیند.این مالکیت فقط به نوشتن کد محدود نیست. تیم باید بتواند درباره توسعه، نگهداری، مشکلات عملیاتی و آینده بخشی که در اختیار دارد تصمیم بگیرد.در این مدل، تیم‌های دیگر می‌توانند درخواست تغییر یا پیشنهاد ارائه کنند، اما مالکیت مستقیم سیستم همچنان در اختیار همان تیم باقی می‌ماند.بار شناختی، محدودیت واقعی تیم‌هایک تیم هرچقدر هم توانمند باشد، ظرفیت ذهنی نامحدودی ندارد. Team Topologies این محدودیت را با مفهوم Cognitive Load یا بار شناختی وارد طراحی سازمان و معماری نرم‌افزار می‌کند.بار شناختی به سه نوع تقسیم شده است:بار شناختی ذاتی که به دانش و مهارت لازم برای انجام خود کار مربوط است.بار شناختی اضافی که از پیچیدگی‌های غیرضروری محیط کار ایجاد می‌شود، مثل به خاطر سپردن مراحل پیچیده برای راه‌اندازی یک محیط تست.بار شناختی مرتبط که صرف حل مسئله اصلی و بخش ارزش‌آفرین کار می‌شود.هدف این است که بار اضافی تا حد ممکن حذف شود، بار ذاتی با آموزش و ابزار مناسب کاهش پیدا کند و ظرفیت ذهنی تیم برای حل مسئله اصلی باقی بماند.این موضوع روی معماری سیستم هم اثر می‌گذارد. اگر یک تیم مسئول تعداد زیادی سیستم، تکنولوژی و دامنه پیچیده باشد، بعد از مدتی دیگر نمی‌تواند همه آن‌ها را به شکل مؤثر درک و مدیریت کند.راه‌حل لزوما اضافه کردن افراد بیشتر نیست. اضافه شدن افراد، مسیرهای ارتباطی بیشتری ایجاد می‌کند و ممکن است مسئله را پیچیده‌تر کند. به همین دلیل، اندازه مسئولیت تیم نیز باید محدود شود.برای مثال، یک تیم می‌تواند چند دامنه ساده را مدیریت کند، اما اگر مسئول یک دامنه بسیار پیچیده است، بهتر است همان یک حوزه تمرکز اصلی آن باشد. سپردن هم‌زمان دو دامنه پیچیده به یک تیم معمولا باعث تقسیم شدن تمرکز و افزایش بار شناختی می‌شود.در Team Topologies، اندازه و مرز نرم‌افزار باید با توان شناختی تیمی که مالک آن است هماهنگ باشد. این نگاه بعداً مبنای تصمیم‌گیری درباره مرز سرویس‌ها، زیرسیستم‌ها و حتی معماری سیستم می‌شود.چهار توپولوژی اصلی تیم در Team Topologiesیکی از مشکلات رایج در سازمان‌ها، زیاد شدن انواع تیم‌ها و مبهم شدن مرز مسئولیت آن‌هاست. ممکن است هم‌زمان تیم زیرساخت، تیم ابزارسازی، تیم دیتابیس، تیم عملیات، تیم معماری، تیم تست و چندین تیم تخصصی دیگر وجود داشته باشند، بدون اینکه مشخص باشد هرکدام دقیقاً چه نقشی در جریان تحویل نرم‌افزار دارند.Team Topologies برای کاهش این پیچیدگی، چهار نوع اصلی تیم تعریف می‌کند:Stream-aligned TeamEnabling TeamComplicated-subsystem TeamPlatform Teamهدف این نیست که صرفا نام تیم‌های موجود تغییر کند. مسئولیت، مرز و نحوه تعامل هر تیم باید با یکی از این چهار مدل هماهنگ شود. در این ساختار، تیم مستقلی با عنوان عمومی Ops یا Support که نرم‌افزار پس از توسعه به آن تحویل داده شود، در نظر گرفته نمی‌شود. تیمی که سیستم را می‌سازد باید به محیط عملیاتی آن نیز نزدیک باشد و مسئولیت عملیات و پشتیبانی از جریان کاری خودش را بر عهده بگیرد.1. Stream-aligned Team -> تیم هم‌راستا با جریانStream-aligned Team اصلی‌ترین نوع تیم در این مدل است. این تیم روی یک جریان مشخص از ارزش کسب‌وکار متمرکز می‌شود. این جریان می‌تواند یک محصول، سرویس، مجموعه‌ای از قابلیت‌ها، سفر کاربر یا حتی یک گروه مشخص از کاربران باشد.تیم باید بتواند تغییر مورد نیاز مشتری را با کمترین وابستگی به سایر تیم‌ها از ابتدا تا انتها پیش ببرد. به همین دلیل، تیم‌های هم‌راستا با جریان موقتی و پروژه‌ای نیستند، بلکه برای مدت طولانی مسئول یک حوزه مشخص باقی می‌مانند.در آمازون، هر تیم مسئول توسعه و اجرای سرویس خودش است و سرویس‌ها از طریق API با یکدیگر ارتباط برقرار می‌کنند. تیم همچنین باید مهارت‌های مورد نیاز برای طراحی، توسعه، تست، زیرساخت و پشتیبانی سرویس را در اختیار داشته باشد.البته منظور این نیست که برای هر مهارت باید یک متخصص جداگانه داخل تیم وجود داشته باشد. مجموع اعضای تیم باید بتوانند قابلیت‌های لازم را پوشش دهند. ترکیبی از افراد با مهارت‌های گسترده و متخصصان حوزه‌های خاص می‌تواند این نیاز را تأمین کند.رفتاری که از چنین تیمی انتظار می‌رود، داشتن جریان پایدار تحویل، واکنش سریع به بازخورد، رسیدگی به بدهی فنی و کاهش پاس‌کاری کار به تیم‌های دیگر است.2. Enabling Team -> تیم توانمندسازتیم هم‌راستا با جریان نمی‌تواند هم‌زمان با تحویل مستمر نرم‌افزار، درباره تمام فناوری‌ها و روش‌های جدید تحقیق عمیق انجام دهد. Enabling Team برای حل همین مسئله شکل می‌گیرد.این تیم معمولا از افرادی تشکیل می‌شود که در یک حوزه مشخص دانش بیشتری دارند و می‌توانند به تیم‌های دیگر در یادگیری یک فناوری، روش یا قابلیت جدید کمک کنند. موضوع کار می‌تواند تست خودکار، Continuous Delivery یا هر حوزه دیگری باشد که تیم مقصد در آن نیاز به توانمندسازی دارد.نکته مهم این است که Enabling Team نباید به یک مرجع دائمی تبدیل شود که سایر تیم‌ها برای انجام کار به آن وابسته باشند. همکاری باید موقت باشد. تیم توانمندساز مدتی در کنار تیم دیگر کار می‌کند، دانش و روش مورد نیاز را منتقل می‌کند و زمانی که آن تیم توانایی انجام مستقل کار را پیدا کرد، کنار می‌رود.به طور مثال در BCG Digital Ventures، یک تیم توانمندسازی مهندسی برای حل مشکلاتی مانند چرخه‌های طولانی انتشار و سیلوهای دانشی ایجاد شد. این تیم ۲۵ درصد زمان خود را صرف کدنویسی و ۷۵ درصد را صرف آموزش و انتقال دانش کرد. طبق متن، زمان استقرار ۷۲ درصد کاهش یافت و زمان اجرای Pipeline از ۱۰ ساعت به ۱۵ دقیقه رسید.این نمونه تفاوت مهم تیم توانمندساز با یک تیم خدماتی دائمی را نشان می‌دهد. هدف آن انجام کار به جای دیگران نیست، بلکه افزایش توانایی خود آن تیم‌هاست.3. Complicated-subsystem Team -> تیم زیرسیستم پیچیدهبعضی قسمت‌های سیستم به دانش تخصصی بسیار عمیقی نیاز دارند. قرار دادن این پیچیدگی داخل یک Stream-aligned Team ممکن است بار شناختی آن را بیش از حد افزایش دهد.در چنین شرایطی می‌توان از Complicated-subsystem Team استفاده کرد. این تیم مسئول بخشی از سیستم است که کار روی آن به تخصصی نیاز دارد که انتظار داشتن آن از تمام تیم‌های دیگر منطقی نیست.نمونه‌های مطرح‌شده در کتاب شامل الگوریتم پیچیده کدک ویدئویی، مدل‌های پیچیده ریاضی، پردازش بلادرنگ معاملات مالی و موتور تشخیص چهره هستند.این مدل با Component Teamهای سنتی تفاوت دارد. هر قطعه کدی که توسط چند تیم استفاده می‌شود نباید الزاماً یک تیم مستقل داشته باشد. تشکیل Complicated-subsystem Team زمانی توجیه دارد که پیچیدگی فنی و بار شناختی آن زیرسیستم واقعاً به یک گروه متخصص نیاز داشته باشد.تعداد این تیم‌ها در یک سازمان باید محدود باشد. بخش عمده سیستم همچنان باید در اختیار تیم‌های هم‌راستا با جریان باقی بماند.4. Platform Team -> تیم پلتفرمPlatform Team با هدف کاهش بار شناختی تیم‌های هم‌راستا با جریان ایجاد می‌شود.اگر هر تیم توسعه مجبور باشد خودش سیستم مانیتورینگ، Logging، زیرساخت، محیط اجرا، Pipeline استقرار و قابلیت‌های مشابه را از ابتدا طراحی و نگهداری کند، بخش زیادی از ظرفیت ذهنی آن صرف مسائلی می‌شود که مستقیما به حوزه کسب‌وکارش مربوط نیستند.تیم پلتفرم این قابلیت‌های مشترک را به شکلی قابل استفاده برای سایر تیم‌ها فراهم می‌کند. این قابلیت‌ها تا جای ممکن باید Self-service باشند. یعنی تیم توسعه بتواند بدون ثبت تیکت و منتظر ماندن برای انجام دستی کار توسط تیم پلتفرم، سرویس مورد نیازش را دریافت کند.پلتفرم نیز باید مانند یک محصول دیده شود. کاربران آن، توسعه‌دهندگان داخل سازمان هستند. بنابراین APIها، مستندات، قابلیت اطمینان و تجربه توسعه‌دهنده یا Developer Experience اهمیت دارند.در کتاب بر مفهوم Thinnest Viable Platform یا TVP نیز تأکید شده است. پلتفرم نباید از ابتدا تبدیل به مجموعه‌ای بزرگ و پیچیده از قابلیت‌ها شود. باید از کوچک‌ترین پلتفرمی شروع کرد که نیاز واقعی تیم‌ها را پاسخ می‌دهد و فقط در صورت نیاز آن را توسعه داد.در سازمان‌های بزرگ ممکن است خود پلتفرم آن‌قدر گسترده شود که یک تیم نتواند آن را مدیریت کند. در این صورت، داخل مجموعه پلتفرم نیز می‌توان دوباره از همین توپولوژی‌ها استفاده کرد. برای تیم‌های بیرونی، پلتفرم همچنان مانند یک سرویس یکپارچه دیده می‌شود، حتی اگر در پشت آن چندین تیم فعالیت کنند.تیم‌های سنتی در این مدل چه می‌شوند؟اجرای Team Topologies معمولا به این معنی نیست که تمام نیروهای تیم‌های قدیمی حذف شوند. مسئله این است که نقش آن‌ها باید دوباره تعریف شود.برای مثال، یک تیم زیرساخت سنتی که درخواست تیم‌های توسعه را دریافت و منابع مورد نیازشان را به صورت دستی ایجاد می‌کند، یک گلوگاه در جریان کار است. چنین تیمی می‌تواند به Platform Team تبدیل شود و همان قابلیت‌ها را به صورت Self-service ارائه کند.برای تیم DBA نیز یک پاسخ واحد وجود ندارد. اگر متخصصان دیتابیس روی آموزش Performance و انتقال دانش به تیم‌های توسعه تمرکز کنند، نقش آن‌ها به Enabling Team نزدیک می‌شود. اگر سرویس آماده دیتابیس، پیکربندی و قابلیت‌های عملیاتی ارائه کنند، می‌توانند بخشی از Platform باشند. کارهای مربوط به خود اپلیکیشن نیز تا جای ممکن به تیمی منتقل می‌شود که آن اپلیکیشن را توسعه می‌دهد.برای Support نیز مدل مشابهی وجود دارد. به جای یک تیم مرکزی که تمام سیستم‌ها را بدون شناخت عمیق از آن‌ها پشتیبانی کند، پشتیبانی باید به جریان کاری مربوط به همان سیستم نزدیک شود.کتاب برای Incidentهای گسترده از مفهوم Swarming استفاده می‌کند. در حالت عادی هر تیم مشکل حوزه خودش را حل می‌کند. اگر حادثه چند بخش سیستم را درگیر کند، متخصصان تیم‌های مختلف به صورت موقت کنار یکدیگر قرار می‌گیرند تا مشکل را برطرف کنند و بعد از پایان حادثه دوباره به ساختار عادی خود بازمی‌گردند.نقش Architecture Team نیز تغییر می‌کند. تصمیم معماری نباید صرفا توسط گروهی جدا از تیم‌های پیاده‌سازی گرفته و سپس به توسعه‌دهندگان ابلاغ شود. معماران می‌توانند نقش توانمندساز داشته باشند، با تیم‌ها کار کنند، ابزار و مشورت ارائه دهند و به پیدا کردن مرزها و APIهای مناسب کمک کنند.نسبت تیم‌های اصلی و تیم‌های کمکیساختار Team Topologies زمانی درست عمل می‌کند که بیشتر سازمان از تیم‌های هم‌راستا با جریان تشکیل شده باشد. سه نوع دیگر برای ساده‌تر کردن کار این تیم‌ها وجود دارند، نه اینکه خودشان به مرکز سازمان تبدیل شوند.نسبت Stream-aligned Teamها به سایر تیم‌ها حدود ۶ به ۱ تا ۹ به ۱ تخمین زده شده است. یعنی در ساختار مورد نظر، بخش بزرگی از ظرفیت سازمان مستقیما روی جریان‌های ارزش کسب‌وکار قرار می‌گیرد و تیم‌های Platform، Enabling و Complicated-subsystem نقش پشتیبان آن‌ها را دارند.مرز تیم باید با مرز نرم‌افزار هماهنگ باشدتعریف چهار نوع تیم به تنهایی کافی نیست. باید مشخص شود هر Stream-aligned Team دقیقا مالک کدام بخش از سیستم است.اگر مرزها اشتباه انتخاب شوند، تیمی که روی کاغذ مستقل است در عمل برای کوچک‌ترین تغییر مجبور خواهد بود با چند تیم دیگر هماهنگ شود.یکی از خطرهایی که کتاب مطرح می‌کند Distributed Monolith است. ممکن است یک سیستم ظاهرا به چند Microservice تقسیم شده باشد، اما اگر برای یک تغییر ساده لازم باشد چند سرویس هم‌زمان تغییر کنند و چند تیم با یکدیگر هماهنگ شوند، استقلال مورد انتظار از معماری میکروسرویس به دست نیامده است.مرز مناسب باید به اندازه‌ای باشد که یک تیم بتواند آن را درک کند، توسعه دهد و در بلندمدت مالک آن باقی بماند. بنابراین انتخاب اندازه سرویس‌ها فقط یک مسئله فنی نیست و باید با Cognitive Load تیم هماهنگ شود.پیدا کردن محل مناسب برای شکستن سیستمبرای شکستن سیستم‌های بزرگ، از مفهوم Fracture Planes یا صفحات شکست استفاده می‌کنیم. ایده این است که به جای تقسیم تصادفی سیستم، نقاطی پیدا شوند که جداسازی در آن‌ها طبیعی‌تر است.یکی از اصلی‌ترین گزینه‌ها Bounded Context در Domain-Driven Design است. در این روش، سیستم بر اساس دامنه‌های منسجم کسب‌وکار تقسیم می‌شود. به طور مثال یک سرویس Streaming موسیقی می‌تواند حوزه‌هایی مانند کشف رسانه، تحویل رسانه و مدیریت Licensing داشته باشد.اما دامنه کسب‌وکار تنها معیار موجود نیست. مرز سیستم ممکن است بر اساس قوانین و Compliance، سرعت تغییر بخش‌های مختلف، موقعیت جغرافیایی تیم‌ها، سطح ریسک، نیازهای Performance یا حتی Personaهای مختلف کاربران تعیین شود.برای نمونه، بخشی که روزانه چندین بار تغییر می‌کند ممکن است بهتر باشد از بخشی که هر سه ماه یک‌بار Release می‌شود جدا شود. همین منطق درباره بخش‌های دارای الزامات قانونی متفاوت یا نیازهای مقیاس‌پذیری بسیار متفاوت نیز صدق می‌کند.هدف، رسیدن به مرزی است که یک تیم بتواند در محدوده آن تا حد زیادی مستقل عمل کند.سه حالت تعامل بین تیم‌هاحتی با بهترین مرزبندی، تیم‌ها کاملا از یکدیگر جدا نیستند. سؤال مهم بعدی این است که وقتی دو تیم باید با یکدیگر ارتباط داشته باشند، این ارتباط چه شکلی داشته باشد.Team Topologies سه حالت اصلی برای تعامل تعریف می‌کند:همکاریدر همکاری دو تیم برای مدتی نزدیک با یکدیگر کار می‌کنند. این حالت بیشتر زمانی مناسب است که عدم قطعیت بالاست و هنوز راه‌حل، فناوری یا مرز مناسب سیستم مشخص نشده است.مزیت آن یادگیری و کشف سریع است، اما هزینه هم دارد. همکاری نزدیک باعث افزایش ارتباطات و مصرف ظرفیت ذهنی هر دو تیم می‌شود و ممکن است مرز مسئولیت آن‌ها را مبهم کند. به همین دلیل همکاری نباید بدون دلیل به وضعیت دائمی تبدیل شود.X-as-a-Serviceدر این حالت، یک تیم قابلیتی مانند API، ابزار، سرویس یا پلتفرم را ارائه می‌کند و تیم دیگر بدون نیاز به ارتباط روزانه از آن استفاده می‌کند.این مدل زمانی مناسب است که مرزها مشخص و سرویس نسبتا پایدار شده باشد. کیفیت این تعامل فقط به درست کار کردن فناوری وابسته نیست. تجربه تیم مصرف‌کننده نیز مهم است. API، مستندات، امکانات و نحوه استفاده باید آن‌قدر روشن باشد که تیم دیگر بتواند تا حد امکان مستقل از ارائه‌دهنده کار کند.گاهی رسیدن به X-as-a-Service نیازمند یک دوره همکاری است. دو تیم ابتدا نزدیک با هم کار می‌کنند تا نیازها و مرز سرویس را پیدا کنند. زمانی که سرویس به وضعیت مناسبی رسید، تعامل روزانه کاهش پیدا می‌کند و رابطه به X-as-a-Service تبدیل می‌شود.تسهیلدر تسهیل یک تیم به تیم دیگری کمک می‌کند تا مانع مشخصی را پشت سر بگذارد یا قابلیت جدیدی یاد بگیرد.رابطه Enabling Team با Stream-aligned Team معمولا از این نوع است. تیم کمک‌کننده قرار نیست مسئولیت کار را برای همیشه بر عهده بگیرد. هدف این است که دانش یا توانایی لازم منتقل شود و تیم دریافت‌کننده بعداً بتواند مستقل ادامه دهد.برای موفقیت این مدل، یک طرف باید توانایی انتقال دانش و کمک کردن داشته باشد و طرف دیگر نیز آماده یادگیری و دریافت کمک باشد.چرا ساختار تیم‌ها باید به مرور تغییر کند؟Team Topologies یک ساختار ثابت برای سازمان پیشنهاد نمی‌کند. تیم‌ها، مرز مسئولیت آن‌ها و نوع تعاملشان باید همراه با تغییر شرایط تکامل پیدا کند. ممکن است در مرحله‌ای از توسعه محصول، دو تیم برای کشف یک راه‌حل جدید نیاز به همکاری نزدیک داشته باشند، اما بعد از مشخص شدن راه‌حل، ادامه همان سطح از ارتباط فقط هزینه ایجاد کند. در این مرحله، رابطه می‌تواند به X-as-a-Service تبدیل شود تا هر تیم مستقل‌تر کار کند.مدل‌های تعامل مختلف می‌توانند هم‌زمان در یک سازمان وجود داشته باشند. یک تیم ممکن است از پلتفرم فقط به صورت سرویس استفاده کند، تیم دیگری برای بررسی یک فناوری جدید با همان تیم پلتفرم همکاری نزدیک داشته باشد و تیم دیگری موقتاً از یک Enabling Team کمک بگیرد. نکته اصلی این است که نوع تعامل مشخص باشد و متناسب با هدف و شرایط تغییر کند.این تغییر نباید صرفا بر اساس تصمیم‌های مقطعی مدیریتی انجام شود. خود سازمان باید نشانه‌هایی را که از نامناسب شدن ساختار خبر می‌دهند تشخیص دهد. کند شدن جریان کار، زیاد شدن وابستگی بین تیم‌ها، بزرگ شدن بیش از حد یک تیم یا افزایش اصطکاک در تعاملات، همگی می‌توانند نشانه‌ای باشند که مرزها یا ساختار موجود دیگر مناسب نیستند.یکی از این نشانه‌ها زمانی است که یک نرم‌افزار آن‌قدر بزرگ می‌شود که دیگر یک تیم نمی‌تواند آن را به طور کامل درک و مدیریت کند. در این حالت معمولا چند نفر به گلوگاه تبدیل می‌شوند، بخش زیادی از دانش سیستم در اختیار آن‌ها قرار می‌گیرد و بقیه برای انجام تغییرات باید منتظر بمانند. چنین وضعیتی نشان می‌دهد که باید مرز نرم‌افزار و مسئولیت تیم دوباره بررسی شود.این همان جایی است که مفهوم Cognitive Load دوباره وارد تصمیم‌گیری می‌شود. مرزهای یک سیستم نباید برای همیشه ثابت فرض شوند. وقتی اندازه یا پیچیدگی بخش تحت مالکیت یک تیم از ظرفیت آن فراتر رفت، باید آن را دوباره تقسیم کرد.Team Topologies به تنهایی کافی نیستحتی اگر چهار نوع تیم به درستی انتخاب شوند و تعاملات هم مشخص باشند، ساختار تیمی به تنهایی نمی‌تواند مشکلات یک سازمان نرم‌افزاری را حل کند.اول، سازمان به یک فرهنگ سالم نیاز دارد؛ محیطی که افراد بتوانند مشکلات را بیان کنند، از اشتباهات یاد بگیرند و برای بهتر شدن روش کار خود اقدام کنند.عامل دوم، بلوغ روش‌های مهندسی است. ساختار تیمی مناسب زمانی اثر واقعی خود را نشان می‌دهد که شیوه‌های مهندسی نیز از جریان سریع تغییرات پشتیبانی کنند.عامل سوم به مدل مالی و بودجه‌بندی مربوط می‌شود. ساختار مالی نباید با ایجاد مرزهای سخت میان CapEx و OpEx یا بودجه‌بندی کاملا پروژه‌محور، تیم‌های پایدار را مجبور کند فقط برای مدت کوتاهی شکل بگیرند و پس از پایان یک پروژه از هم جدا شوند. تصمیم‌های مالی نیز باید با ساختار تیمی هماهنگ باشند.در کنار این موارد، چشم‌انداز کسب‌وکار باید برای تیم‌ها روشن باشد. اگر تیم اختیار بیشتری برای تصمیم‌گیری دارد، باید بداند سازمان به دنبال چه نتیجه‌ای است و اولویت‌ها بر چه مبنایی انتخاب می‌شوند.Team Topologies مشخص می‌کند هر بخش در کجا قرار بگیرد، اما فرهنگ، مهندسی و ساختار مالی مانند شرایطی هستند که رشد آن مجموعه را ممکن می‌کنند. طراحی مناسب تیم‌ها در محیط نامناسب، به تنهایی نتیجه مورد انتظار را ایجاد نمی‌کند.برای اجرای Team Topologies از کجا شروع کنیم؟نقطه شروع، خود تیم است.به جای اینکه سازمان ابتدا کل چارت را بازطراحی کند یا مستقیما به سراغ ساخت یک Platform بزرگ برود، بهتر است ابتدا وضعیت تیم‌ها را بررسی کند. هر تیم باید بتواند مسئولیت مشخصی داشته باشد، مالک بخشی از نرم‌افزار باشد، روی نیاز کاربر تمرکز کند و برای انجام کار روزانه دائماً میان تیم‌های دیگر سرگردان نشود.از همین نقطه می‌توان چند سوال مطرح کرد: آیا مسئولیت این تیم با ظرفیت شناختی آن متناسب است؟ آیا محدوده نرم‌افزار تحت مالکیتش مشخص است؟ برای تحویل یک تغییر به چند تیم دیگر وابسته است؟ کدام تعامل‌ها واقعاً لازم هستند و کدام‌یک فقط از ساختار نامناسب به وجود آمده‌اند؟بعد از شناخت این وضعیت می‌توان درباره معماری، ابزارها، محیط کاری، پلتفرم و تقسیم سرویس‌ها تصمیم گرفت. یعنی ساختار فنی باید از نیازهای واقعی تیم و جریان کار حمایت کند، نه اینکه تیم‌ها مجبور شوند خود را با ساختاری که از قبل و بدون توجه به آن‌ها طراحی شده تطبیق دهند.در طراحی یا بازطراحی تیم‌ها، چهار سوال مشخص را نیز مطرح می‌شود:با توجه به مهارت‌ها، محدودیت‌ها، بلوغ فرهنگی و مهندسی، معماری مورد نظر و اهداف کسب‌وکار، چه توپولوژی تیمی مناسب‌تر است؟چگونه می‌توان Handoverها را در مسیر اصلی تغییرات کاهش داد یا حذف کرد؟مرزهای سیستم در کجا قرار بگیرند تا جریان کار سریع باقی بماند؟تیم‌ها چگونه باید با این مرزهای نرم‌افزاری هماهنگ شوند؟این سؤال‌ها کمک می‌کنند تغییر ساختار به جای واکنش به یک بحران لحظه‌ای، بر اساس جریان واقعی کار و محدودیت‌های تیم انجام شود.فهم کلی من از کتابTeam Topologies مسئله طراحی سازمان را مستقیما به نحوه ساخت نرم‌افزار مرتبط می‌کند. ساختار تیم‌ها، مرز مسئولیت آن‌ها و مسیرهای ارتباطی‌شان روی معماری سیستم اثر می‌گذارند و به همین دلیل نمی‌توان معماری نرم‌افزار را جدا از ساختار انسانی سازمان طراحی کرد.قانون کانوی این ارتباط را توضیح می‌دهد، Team-First Thinking تیم را واحد اصلی انجام کار در نظر می‌گیرد و Cognitive Load مشخص می‌کند که هر تیم چه مقدار پیچیدگی را می‌تواند مدیریت کند. بر همین اساس، چهار نوع تیم Stream-aligned، Enabling، Complicated-subsystem و Platform تعریف می‌شوند و Collaboration، X-as-a-Service و Facilitating نیز شکل تعامل میان آن‌ها را مشخص می‌کنند.اما این ساختار یک نسخه ثابت نیست. با تغییر محصول، فناوری، اندازه سیستم و نیازهای سازمان، مرز تیم‌ها و مدل تعامل آن‌ها نیز باید تغییر کند. کند شدن جریان کار، افزایش وابستگی‌ها و زیاد شدن بار شناختی نشانه‌هایی هستند که می‌توانند نیاز به این تغییر را آشکار کنند.بسیاری از مشکلات توسعه نرم‌افزار فقط از کمبود ابزار یا فناوری ناشی نمی‌شوند. ساختار نامناسب تیم‌ها، مسئولیت‌های مبهم، تعاملات بدون الگوی مشخص و نادیده گرفتن بار شناختی نیز می‌توانند باعث کاهش سرعت، افزایش وابستگی و پیچیده شدن معماری شوند. Team Topologies مدلی برای طراحی این بخش از سازمان ارائه می‌کند تا تیم‌ها بتوانند تغییرات را بهتر مدیریت کنند و جریان تحویل نرم‌افزار پایدارتر بماند.اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است.منبع: Team Topologies: Organizing Business and Technology Teams for Fast Flowنوشته: Manuel Pais و Matthew Skeltonدیبا میرشفیعیدیبا میرشفیعیTue, 11 Aug 2026 14:37:00 +0330https://virgool.ir/@m_12585742/معماری-طراحی-نرم-افزار-و-شفافیت-در-مقیاس-بالا-qqzsm6zocashدر دنیای پیچیده توسعه نرم‌افزار، مقیاس‌پذیری تنها به زیرساخت‌ها محدود نمی‌شود، بلکه به نحوه تصمیم‌گیری و ارتباطات انسانی نیز بستگی دارد. در گفتگویی که در رویداد GOTO 2025 برگزار شد، مفاهیم عمیق معماری نرم‌افزار در سازمان‌های بزرگ مورد بررسی قرار گرفت. تمرکز اصلی این پنل، تبدیل فرآیند معماری از یک رویکرد دستوری به جریانی مشارکتی و پویا بود.بازتعریف طراحی در تمام سطوحیکی از مفاهیم کلیدی مطرح شده در این نشست، اصلاح دیدگاه رایج نسبت به کلمه طراحی است. طراحی نرم‌افزار صرفا به معنای چیدمان کدها یا خلق UI/UX نیست، بلکه مفهومی فراگیر است که از درک نیازمندی‌های تجاری تا معماری و در نهایت مهندسی سیستم جریان دارد.با توجه به مدل ارتباطی ACE، در هر لایه از سازمان یک Context مشخص وجود دارد. از قوانین و مقررات در سطح کلان سازمانی گرفته تا محدودیت‌های درون‌تیمی، که همگی به‌طور مستقیم بر تصمیمات طراحی اثر می‌گذارند.چالش ارتباطات: تکرار مداوم پیاموقتی مقیاس تیم مهندسی به صدها توسعه‌دهنده می‌رسد، انتقال مفاهیم و تصمیمات به چالشی اساسی تبدیل می‌شود. توسعه‌دهندگان در کدنویسی به شدت به اصل خودت را تکرار نکن یا DRY پایبندند، اما در ارتباطات انسانی سازمانی باید از رویکرد به‌طور مداوم خودت را تکرار کن یا CRY استفاده کرد. برای نهادینه کردن یک تصمیم در یک سازمان بزرگ، نمی‌توان تنها به یک بار اعلام آن بسنده کرد. مهم‌تر از آن، مستندات و تصمیمات باید در ابزارهایی قرار بگیرند که افراد به‌طور روزمره با آن‌ها کار می‌کنند، نه اینکه تیم‌ها مجبور به یادگیری و مراجعه به یک ابزار یا پلتفرم جدید شوند.قدرت سوابق تصمیم‌گیری یا ADRsثبت سوابق تصمیم‌گیری معماری یا ADR یکی از مهم‌ترین ابزارهای هماهنگی در مقیاس بالاست. مهم‌ترین کارکرد این سوابق، ثبت چرایی اتخاذ یک تصمیم است. مستند کردن دلایل باعث می‌شود تا اگر در آینده شرایط کسب‌وکار تغییر کرد، سازمان بداند که آیا می‌تواند آن تصمیم را لغو کند یا خیر. این کار همچنین از پدیده اتلاف وقت برای پاسخگویی مکرر به دلایل تصمیمات گذشته جلوگیری کرده و فرآیند آشناسازی نیروهای جدید را با ارجاع به چند تصمیم کلیدی بسیار سریع‌تر می‌کند. برای ترغیب مهندسان به مشارکت بیشتر در این فرآیند، اگر معماری جدید را با عنوان Draft منتشر کنید، توسعه‌دهندگان احساس امنیت و آزادی بیشتری برای نقد و ارائه بازخورد خواهند داشت.حلقه‌های بازخورد متقابلدر نهایت، معماری موفق نیازمند Feedback loops پیوسته است. اطلاعات و تصمیمات نباید تنها از سمت کسب‌وکار یا معماران به توسعه‌دهندگان سرازیر شود، بلکه باید مسیری برای بازگشت این بازخوردها نیز وجود داشته باشد. استفاده از ابزارهای نظارت بر سیستم در محیط پروداکشن در کنار صحبت مستقیم با مهندسان درباره کارایی تصمیمات، برای سنجش موفقیت معماری حیاتی است. اگر مهندسان احساس کنند تصمیماتی ناکارآمد به آن‌ها تحمیل شده و صدایشان شنیده نمی‌شود، کل ساختار و کیفیت نرم‌افزار در درازمدت آسیب خواهد دید.اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است.منابع ارجاع:نام ارائه: SW Design, Architecture & Clarity at Scaleارائه‌دهندگان: Sam Newman, Jacqui Read, Simon Rohrerرویداد: GOTO 2025لینک: https://youtu.be/t67oWHa00iE?si=6cuNI3oL_9jyT6o_دیبا میرشفیعیدیبا میرشفیعیSat, 11 Jul 2026 23:12:37 +0330https://virgool.ir/@m_12585742/الهام-از-طبیعت-برای-حل-یک-بحران-نرم-افزاری-tnxt8qrf6tmfداستان ما با یک ارگانیسم تک‌سلولی زرد رنگ به نام کپک مخاطی آغاز می‌شود. دانشمندان با قرار دادن منابع غذایی در اطراف شهر توکیو متوجه شدند که این ارگانیسم می‌تواند بدون نیاز به یک تصمیم‌گیرنده مرکزی، با تصمیم‌گیری‌های محلی شبکه‌ای پیچیده و بسیار کارآمد شبیه به سیستم متروی توکیو بسازد. این رفتار مستقل، الهام‌بخش تیم مهندسی نرم‌افزاری شد که در سال ۲۰۲۰ با یک سیستم یکپارچه و قدیمی دست‌وپنجه نرم می‌کردند. آن‌ها با سیستمی پر از خطاهای استقرار دستی و چرخه‌های انتشار بسیار کند که بین ۳ تا ۶ ماه زمان می‌برد، مواجه بودند. هدف آن‌ها گذر از این وضعیت و بازطراحی سیستم به یک پلتفرم ابری با استفاده از روش‌های مدرن مهندسی بود و برای این کار تصمیم گرفتند از الگوی غیرمتمرکز کپک مخاطی پیروی کنند.تقسیم سیستم و قدرت‌بخشی به تیم‌هاتیم توسعه برای رهایی از این ساختار درهم‌تنیده، با استفاده از اصول DDD، سیستم را به بخش‌های مستقل و با ارتباطات سست تقسیم کرد و یک نمای کلی به نام Context Map به وجود آورد. مالکیت و مسئولیت توسعه ویژگی‌های جدید، بازطراحی و رفع باگ هر بخش از این نقشه به یک تیم مشخص واگذار شد. با مستقل شدن تیم‌ها، نیاز به یک ساختار حمایتی برای هدایت تصمیم‌گیری‌ها حس می‌شد. به همین دلیل، آن‌ها ۱۶ اصل معماری همسو با استراتژی‌های تجاری شرکت تدوین کردند تا چارچوبی روشن برای تصمیمات تیم‌ها شکل بگیرد. قانون اصلی که تحت عنوان فرآیند مشاوره معرفی شد بسیار ساده بود: هر تیمی می‌تواند هر تصمیمی بگیرد، به این شرط که از تمامی افراد متخصص و گروه‌های متاثر از آن تصمیم، مشاوره دریافت کند و دلایل موافقت و مخالفت را به صورت عمومی ثبت نماید.ثبت و اشتراک‌گذاری تصمیماتبرای جلوگیری از هرج‌ومرج ناشی از استقلال تیم‌ها، ابزاری به نام سوابق تصمیمات معماری یا ADRs معرفی شد. این اسناد کوتاه، نشان‌دهنده چرایی و چگونگی یک تصمیم، گزینه‌های جایگزین بررسی‌شده، پیامدهای مثبت و منفی، و مشاوره‌های دریافت‌شده هستند. این اسناد در سیستم مدیریت پروژه نظیر Azure DevOps به عنوان آیتم‌های کاری ذخیره می‌شوند تا به راحتی توسط همه اعضا قابل جستجو باشند و به عنوان یک مستند زنده و پویا عمل کنند. علاوه بر ثبت، اشتراک‌گذاری این تصمیمات در جلسات هفتگی عمومی به نام انجمن مشاوره معماری انجام می‌شود. در این جلسات که تمامی اعضا می‌توانند در آن شرکت کنند، پیش‌طرح‌ها و ADRهای جدید ارائه می‌شوند تا پیش از نهایی شدن و اتخاذ تصمیم، مورد بحث و بررسی قرار گیرند. همچنین در این انجمن، تاثیر تصمیمات از طریق بررسی هزینه‌های مصرفی فضای ابری و معیارهای عملکردی یا DORA metrics ارزیابی می‌شود.آینده معماران در سیستم غیرمتمرکزیکی از نگرانی‌های رایج این است که با واگذاری تصمیمات به تیم‌ها، معماران نرم‌افزار شغل خود را از دست بدهند، اما اینگونه نیست و جایگاه شغلی آن‌ها کاملا امن است. در واقع نقش آن‌ها تغییر می‌کند؛ معماران از تصمیم‌گیرندگان مطلق به تسهیل‌گرانی ارزشمند تبدیل می‌شوند که در کارگاه‌های تخصصی نظیر مدل‌سازی تهدید و طوفان رویداد به تیم‌ها کمک کرده و به عنوان پل ارتباطی بین آن‌ها عمل می‌کنند. با خارج شدن از گلوگاه تصمیم‌گیری و آزاد شدن وقتشان، آن‌ها می‌توانند روی حل مشکلات پیچیده تمرکز کنند. در نهایت، پیام اصلی این رویکرد روشن است: بیشتر شبیه کپک مخاطی باشید :) به تیم‌های خود قدرت دهید و تصمیم‌گیری‌ها را غیرمتمرکز کنید تا به اهداف مشترک خود دست یابید.اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است.عنوان ارائه: How to Decentralize Architecture Decisions (Without Chaos)ارائه‌دهندگان: Peter Hunter & Elena Stojmilova (ارائه شده در رویداد QCon)لینک مشاهده ویدیو: https://www.youtube.com/watch?v=8xuptSUYV20دیبا میرشفیعیدیبا میرشفیعیSat, 11 Jul 2026 21:35:40 +0330https://virgool.ir/@m_12585742/هر-چی-فهمیدم-از-بعضی-مفاهیم-معماری-نرم-افزار-povafw87m23iاینجا یک سری از موارد پایه‌ای معماری نرم‌افزار رو بررسی میکنیم:اولین مورد:Chaos Engineering:در این رویکرد به‌صورت عمدی و کنترل‌شده، خرابی یا فشاری در سیستم ایجاد میکنیم تا تحمل سیستم را بسنجیم. دلیل انجام این کار این است که نه‌تنها سنجیدن هر یک از سرویس‌ها اهمیت دارد، بلکه ارتباط بین آن‌ها نیز اهمیت دارد. پس سنجش رفتار کل سیستم بسیار اهمیت دارد. پس در این رویکرد نه‌تنها رفتار هر یک از سیستم‌ها را میسنجیم، بلکه ارتباط بین آن‌ها را هم بررسی میکنیم.در این فرآیند اول بررسی میکنیم که سرویس ما در وضعیت پایدار باید چه رفتاری داشته باشد. سپس یک سناریو ایجاد میکنیم که در آن یکی از سرویس‌ها به مشکل بر بخورد یا به‌طور کامل قطع شود. مثلا pod یکی از آن‌ها به‌طور کامل پایین بیاید. سپس بررسی میکنیم در این شرایط آیا کل کارایی از بین میرود و یا سرویس دیگر قابل استفاده نیست یا همچنان میشود از آن استفاده کرد. Basiri, A., Behnam, N., de Rooij, R., Hochstein, L., Kosewski, L., Reynolds, J., & Rosenthal, C. (2017). Chaos Engineering. arXiv:1702.05843 Backend for Frontend:در این الگو برای هر مدل frontend یک کد backend اختصاصی طراحی میشود. یعنی به جای اینکه همه استفاده‌کنندگان از یک API استفاده کنند، هر کدام یک API با نیاز خودش دارد. در این ساختار Frontend فقط همان داده‌ای که نیاز دارد را دریافت میکند.در چنین ساختاری، این لایه بین frontend و backend قرار میگیرد و این لایه میتواند چند API مختلف را صدا کند یا فیلدهای اضافی را حذف کند و خروجی نهایی، همان خروجی قابل استفاده برای آن frontend مورد نظر باشد.به‌طور مثال، امکان دارد که یک کلاینت، در نسخه frontend موبایل خود اطلاعات کمتری نسبت به نسخه وب نیاز داشته باشد. در این شرایط این لایه کمک میکند که نسخه موبایل دقیقا موارد مورد نیاز خود را دریافت کند.Newman, S. Pattern: Backends for FrontendsMicrosoft Azure Community Hub. Implementing the Backend-for-Frontend (BFF) / Curated API Pattern Using Azure API Management Artificial Intelligence for Software Engineering:این مفهوم به معنی استفاده از هوش مصنوعی برای کمک به فرآیندهای مهندسی نرم‌افزار است. در این زمینه AI در تولید کد، تولید تست یا مستندسازی و دیباگ کمک میکند. در اصل، بخشی از کارهای تکراری در توسعه نرم‌افزار خیلی سریع‌تر پیش میرود که میتواند به ما کمک کند زمان بیشتری برای طراحی و تصمیم‌گیری‌های مهم داشته باشیم. البته فقط در تولید کد استفاده نمیشود و میتواند در فرآیندهای نرم‌افزاری، به‌طور مثال از user story تا تولید تست، به ما کمک کند.IBM. AI in Software DevelopmentGoogle for Developers. Gemini Code Assist Overview SE4AI:این مفهوم تقریبا برعکس مورد قبلی است. در این رویکرد از اصول مهندسی نرم‌افزار برای مدیریت و یا ساخت سیستم‌هایی که با هوش مصنوعی کار میکنن، استفاده میکنه. یعنی این سیستم‌های AI بتوانند در تمام حالت‌ها در یک محیط واقعی کار کنند. تفاوت این رویکرد با قبلی در این است که در اینجا موضوع اصلی خود سیستم AI است ولی در مورد قبلی از AI صرفا به‌عنوان کمک استفاده میکنند.بخش مهم در این زمینه MLOps است که موارد و اصول DevOps را به سیستم‌های ML می‌آورد و موارد آن را برای مدل‌های ML خودکار میکند.Google Cloud. MLOps: Continuous delivery and automation pipelines in machine learningMicrosoft. Responsible AI Principles and ApproachMLOps:این مفهوم در مورد قبلی هم توضیح داده شد، ولی به‌صورت مفصل‌تر، این رویکرد باعث میشود مدل‌های ML در محیط‌های واقعی هم قابل اعتمادتر باشند. در DevOps معمولا تمرکز اصلی روی کد و مواردی مانند Deployment هست، اما در MLOps مواردی مثل کد،   monitoring  و ارزیابی مدل هم اهمیت دارد. یکی از اهداف اصلی این رویکرد این است که چرخه عمر مدل‌های ML را خودکارسازی کند و یعنی ما مدل را به‌صورت کامل monitor و تست میکنیم. مفاهیم CI/CD هم در این زمینه استفاده میشود. AWS. What is MLOps? Machine Learning Operations ExplainedGoogle Cloud. MLOps: Continuous delivery and automation pipelines in machine learning Infrastructure as Code (IaC):در این روش، منابعی مثل سرور، شبکه، دیتابیس و این‌گونه موارد زیرساخت، به جای تنظیم دستی، در فایل‌های configuration تعریف میشوند. دلیل استفاده از این رویکرد این است که بتوانیم منابع زیرساختی را قابل استفاده دوباره، قابل نسخه‌بندی و قابل خودکارسازی کنیم. مثلا به جای اینکه یک نفر به‌صورت دستی موارد مورد نیاز را در پنل یا سایر interfaceها وارد کند، موارد و وضعیت مطلوب و مورد نیاز ما در کد نوشته شده و توسط یک سری ابزار ایجاد یا تغییر میکند و اصطلاحا configure میشود. مدیریت دستی موارد زیرساخت در مقیاس بالا میتواند باعث خطای انسانی شود. این روش باعث میشود تنظیمات محیط یکسان‌تر و قابل کنترل باشد. AWS. What is Infrastructure as Code?HashiCorp Developer. Use infrastructure as code API Gateway & Service Mesh:API Gateway یک لایه در ورودی سیستم هست که درخواست‌ها را دریافت میکند و آن‌ها را به سرویس‌های مناسب در backend هدایت میکند. در اصل، یک نقطه ورود واحد برای APIها هست. در این معماری کلاینت لازم نیست با چندین microservice به‌صورت مستقیم در ارتباط باشد، بلکه این موارد از طریق API Gateway انجام میشود.Service Mesh  یک لایه زیرساختی برای مدیریت ارتباطات بین خود سرویس‌ها هست. یعنی بدون نیاز به تغییر کد برنامه، قابلیت‌هایی برای امنیت و کنترل ترافیک فراهم میکند. برای مثال، اگر دو سرویس باید باهم ارتباط بگیرند، service mesh این ارتباط را امن‌تر و قابل کنترل‌تر میکند. پس به‌صورت کلی API Gateway دریچه ورود است برای APIهای سیستم، ولی Service Mesh ارتباطات داخلی بین خود سرویس‌ها را کنترل میکند.AWS. Amazon API GatewayIstio. The Istio Service Mesh CQRS (Command Query Responsibility Segregation):یک الگوی معماری هست که عملیات خواندن داده را از نوشتن یا تغییر دادن سیستم جدا میکند. یعنی در این روش command مسئول تغییر وضعیت سیستم هست و بخش Query فقط برای دیدن داده استفاده میشود. یعنی command معمولا به معنای قصد کاربر برای تغییر یک مورد هست و معمولا این عملیات داده‌ای را تغییر میدهد و نباید مثل query برای نمایش مستقیم داده‌ها استفاده شود. query هم نباید بتواند وضعیت سیستم را تغییر دهد و فقط برای نمایش اطلاعات استفاده میشود. البته این الگو برای تمامی سیستم‌ها مناسب نیست، به دلیل اینکه میتواند پیچیدگی معماری را افزایش دهد. پس بهتر است فقط زمانی استفاده شود که تفاوت جدی بین read و write وجود داشته باشد.Microsoft Learn. CQRS PatternFowler, M. CQRSTechTarget. What is CQRS (Command Query Responsibility Segregation) Event-Driven Architecture (EDA):مانند موارد قبلی، یک الگوی معماری هست که سرویس‌ها با ارسال eventها باهم ارتباط برقرار میکنند که این eventها معمولا نشان‌دهنده یک تغییر وضعیت یا مورد مهمی در سیستم هست. یکی از ویژگی‌های مهم این معماری کاهش وابستگی بین سرویس‌ها هست. یعنی ارسال‌کننده event  نیازی ندارد بداند که چه کسانی این event را دریافت میکنند یا چه کاری برای آن انجام میدهند که وابستگی بین سرویس‌ها را کمتر میکند. اما این رویکرد یک سری چالش‌هایی دارد که بعضی موارد مانند دیباگ کردن را سخت میکند، چون ترتیب این eventها هم میتوانند مهم باشند و به دلیل ارتباط کمتر، trace  کردن این موارد سخت‌تر خواهد شد.پس این معماری برای سیستم‌هایی مناسب هست که رخدادهای زیادی دارند یا نیاز هست سرویس‌ها وابستگی کمتری بهم داشته باشند. اما برای سیستم‌های ساده، پیچیدگی میتواند درست کند.AWS. What is EDA? Event-Driven Architecture ExplainedMicrosoft Learn. Event-driven architecture style Serverless Architecture:در این معماری برنامه‌ها بدون مدیریت مستقیم سرور اجرا میشوند. یعنی در این مدل به‌صورت خودکار بر اساس درخواست‌ها یا eventهای مختلف منابع داده میشوند. یعنی مثلا اگر در زمانی ترافیک زیاد بود، منابع بیشتری فراهم میشود و در زمان کم شدن ترافیک، منابع کم میشوند.در این مدل بر اساس استفاده‌ای که از منابع میشود، هزینه گرفته میشود و در هزینه‌ها بسیار صرفه‌جویی میشود. البته این معماری چالش‌هایی مانند وابسته بودن به cloud provider و سخت‌تر شدن دیباگ دارد. یعنی به دلیل اینکه ما از cloud provider منبع میگیریم، در زمانی که نیاز هست این منابع برای زمانی زیادتر شوند یا کمتر شوند، به cloud provider وابسته میشویم.در اصل این معماری به توسعه‌دهندگان کمک میکند تیم‌ها سریع‌تر توسعه دهند و کمتر درگیر مسائل زیرساخت باشند. AWS. Serverless ComputingGoogle Cloud. ServerlessGoogle Cloud. What is Cloud Run API-first Approach:در این رویکرد APIها از همان اول فرآیند طراحی به‌عنوان بخش اصلی سیستم در نظر گرفته میشوند. یعنی فقط یک خروجی از backend نیست، بلکه برای ارتباطات بین سرویس‌ها و کلاینت‌ها استفاده میشود. در این روش معمولا قبل از نوشتن کد اصلی، به طراحی API پرداخته میشود. این مسئله یک توافق بین تیم‌های مختلف درست میکند و تیم‌ها میتوانند به‌صورت موازی کار کنند. مثلا تیم frontend میتواند با مستندات یک سری mock API درست کند و به جای APIهای اصلی از آن‌ها برای تست استفاده کند که به testability سیستم هم کمک میکند. البته برای پروژه‌های کوچک میتواند پیچیدگی را بیشتر کند.Postman. What is API-first? The API-first Approach ExplainedSmartBear / Swagger. Adopting a Design First Approach with OpenAPI Specification Domain Driven Design:مدل‌سازی در این رویکرد براساس دامنه کسب‌وکار و نیازهای واقعی سیستم هست. یعنی طراحی سیستم فقط از دید فنی انجام نمیشود و مفاهیم کسب‌وکار در آن اثر دارند. دامنه در اینجا همان حوزه کسب‌وکاری هست که برای آن نرم‌افزار میسازیم. مثلا در یک سیستم فروشگاهی، سفارش، پرداخت و ... بخشی از دامنه هستند.این معماری به ما کمک میکند مرز سرویس‌ها را بر اساس مرزهای واقعی کسب‌وکار مشخص کنیم و نه لایه‌های فنی. البته این رویکرد برای تمام پروژه‌ها نیاز نیست و امکان دارد باعث زیاد شدن پیچیدگی در آن‌ها شود. Microsoft Learn. Designing a DDD-oriented microserviceMicrosoft Learn. Use domain analysis to model microservices Martin Fowler. Bounded ContextMicrosoft Learn. Identify microservice boundaries Hexagonal architecture:این معماری برای این معرفی شد که منطق اصلی برنامه از جزئیات فنی آن جدا شود. در این معماری هسته برنامه و مهم‌ترین بخش آن قوانین کسب‌وکار و منطق اصلی آن است و به تکنولوژی‌ای وابستگی ندارد و به جای ارتباط مستقیم با قسمت فنی، از port استفاده میشود.Port در اصل یک interface هست که مشخص میکند منطق برنامه چگونه با دنیای بیرون ارتباط بگیرد. یعنی برای قسمت اصلی برنامه مهم نیست با چه جزئیات فنی‌ای کار میکند. مثلا برای بخش اصلی اهمیت ندارد که از چه دیتابیسی استفاده میشود. Adapter کمک میکند جزئیات فنی بیرون از هسته اصلی را برای آن قابل فهم کند. این معماری تست کردن را بسیار راحت‌تر میکند، چون بخش منطق برنامه به لایه فنی خارج آن وابستگی ندارد. AWS Prescriptive Guidance. Hexagonal architecture patternAWS Prescriptive Guidance. Building hexagonal architectures on AWS – Overview  Event Sourcing:در این الگو، به جای اینکه فقط آخرین وضعیت به‌صورت event ذخیره شود، تمام تغییرات وضعیت به‌صورت کامل ذخیره میشود که هر کدام از این eventها مشخص میکند چه چیزی وضعیت سیستم را تغییر داده است. در این ساختار event جدید به event قبلی اضافه میشود و event قبلی پاک نمیشود. این‌گونه ما یک تاریخچه کامل از تغییرات سیستم داریم که برای دیباگ کردن و گزارش‌گیری به شدت مفید است. وضعیت فعلی در این رویکرد به این صورت مشخص میشود که سیستم به ترتیب آن‌ها را خوانده و با اعمال آن‌ها، وضعیت سیستم را بعد از هر event بازسازی میکند. فقط دقت شود که این الگو زمانی به درد ما میخورد که نیاز داشته باشیم تمام تغییرات قبلی سیستم را داشته باشیم، وگرنه حفظ کردن تمامی این eventها فضای زیادی میتواند بگیرد که برای تمام سیستم‌ها مناسب نیست. Microsoft Learn. Event Sourcing PatternAWS Prescriptive Guidance. Event Sourcing Pattern Low-code/No-code platforms:پلتفرم‌هایی هستند که ساخت اپلیکیشن‌ها و نرم‌افزارها را راحت‌تر کرده و بدون کدنویسی یا با حداقل کدنویسی میشود با آن‌ها نرم‌افزار ساخت. یعنی با داشتن یک interface UI و استفاده از drag and drop و استفاده از templateهای مختلف میتوانیم نرم‌افزار مورد نیاز را داشته باشیم. این رویکرد میتواند فشار را روی تیم‌های فنی کم کند، چون بعضی موارد ساده و تکراری میتواند با تیم‌های غیرفنی پیش برود. البته در پروژه‌هایی که سفارشی هستند میتواند باعث محدودیت شود و کنترل را روی کد کم کند. از طرفی برای customize کردن هم محدودیت درست میکند، چون خیلی از موارد دیگر دست خود تیم فنی نیست. IBM. Low-Code vs. No-Code: What’s the DifferenceAWS. What is Low Code? Low Code ExplainedIBM. What is No-Code? Business Process Management Systems (BPMS):این سیستم‌ها کمک میکنند فعالیت‌ها و وظایف مختلفی که برای یک سازمان هست بهتر مدیریت و هماهنگ شوند. در این فرآیند معمولا اول فرآیندها مدل‌سازی میشوند که به ذی‌نفعان کمک میکند بهتر ارتباطات و فعالیت‌ها را ببینند و درک کنند.هدف این است که به جای اینکه فرآیندها فقط در کاغذها و مستندات باشند، در سیستم قابل پیگیری باشند و برای فرآیندهایی مناسب هست که چند واحد سازمانی و چندین نقش درگیر آن هستند که به افزایش شفافیت کمک میکند و کنترل را روی فرآیندها افزایش میدهد. البته BPMS برای تمام کارها لازم نیست و برای فعالیت‌های کوتاه نیازی به آن نیست. IBM. What is Business Process ManagementTechTarget. What is Business Process Management Software (BPMS)?Microsoft. Power Automate: Business Process Workflow Automation Message Queue (such as Kafka and RabbitMQ):یک واسطه برای ارسال و دریافت پیام بین بخش‌های مختلف سیستم است. به جای اینکه دو سرویس مستقیم بهم وابسته باشند، یک سرویس پیام را داخل یک صف گذاشته و سرویس دیگر بعدا آن را دریافت میکند و پردازش‌های لازم را انجام میدهد. خوبی این روش این هست که نیاز نیست حتما هم دریافت‌کننده و هم فرستنده در دسترس باشند. مثلا اگر یکی از آن‌ها به‌صورت موقت قطع شود، این پیام در صف باقی میماند تا وقتی که مشکل رفع شده و پیام را بتواند بررسی کند. به‌طور مثال، در RabbitMQ صف‌ها معمولا رفتار FIFO دارند. یعنی پیام‌ها به ترتیب پردازش میشوند، ولی میتوانیم تنظیمات مختلفی روی آن‌ها انجام دهیم. AWS. What is a Message Queue?RabbitMQ. Queues Containers (eg., Docker) and Container orchestration (e.g., Kubernetes):Container   در اصل یک بسته قابل اجرا از کد برنامه و dependencyهای آن است که باعث میشود رفتار سیستم در تمام سیستم‌ها به‌صورت یکسان باشد. Containerها به دلیل اینکه سیستم‌عامل جداگانه ندارند سبک هستند و setup سریع‌تری دارند. Docker یکی از ابزارهای مهم هست که کمک میکند تمام موارد برنامه با تمام dependencyها در محیط‌های مختلف قابل Deploy باشند. اگر تعداد containerها کم باشد، میشود با Docker Compose آن را مدیریت کرد ولی اگر تعداد بیشتر باشد، به دلیل پیچیدگی بیشتر باید از ابزارهایی مانند Kubernetes استفاده کنیم. در Kubernetes کوچک‌ترین واحد pod هست که میتواند شامل چند container باشد که همزمان اجرا شده و منابع را باهم به اشتراک میگذارند.پس به‌صورت کلی این ابزارها به ما کمک میکنند که ما بتوانیم یک نرم‌افزار را بدون نیاز به دانستن محیط آن اجرا و مدیریت کنیم. Docker. What is a ContainerKubernetes Documentation. What is Kubernetes? Multi-Tenancy Architecture:در این نوع معماری با یک زیرساخت و نرم‌افزار به چند مشتری سرویس میدهیم. یعنی چند مشتری میتوانند از یک زیرساخت و یا اپلیکیشن استفاده کنند، ولی داده‌ها و تنظیمات متفاوتی نسبت بهم داشته باشند و نمیتوانند به داده‌های هم دست پیدا کنند. مثلا در مدل SaaS یک نرم‌افزار از طریق شبکه ابری به چندین مشتری ارائه میشود.در بعضی سیستم‌ها تمام منابع بین مشتری‌ها به اشتراک گذاشته میشود و در بقیه موارد بعضی منابع فقط مشترک هستند. مزیت این معماری این است که هزینه‌ها کاهش پیدا کرده و از منابع بهتر استفاده شود. البته در این زمینه باید به امنیت داده و کنترل دسترسی هم بسیار دقت کرد که میتواند باعث چالش شود. IBM. What is Multi-Tenant?Microsoft Learn. Architect multitenant solutions on AzureMicrosoft Learn. Tenancy models for a multitenant solution Data Migration:فرآیند انتقال داده‌ها از یک سیستم به سیستم دیگر است که هدف آن این است که داده‌ها با کمترین اختلال و بدون از دست رفتن به مقصد جدید منتقل شوند. یکی از چالش‌های این فرآیند این است که اگر داده‌ها قدیمی باشند، میتواند در سیستم جدید ناسازگار باشد. پس مهم هست قبل از انجام عملیات حتما داده‌ها بررسی شوند. همچنین باید در این فرآیند به امنیت داده‌ها هم اهمیت داد و پس از انجام آن، داده‌ها را حتما بررسی کرد تا مشکلی توی آن‌ها بعد از انتقال وجود نداشته باشد. IBM. What is Data MigrationAWS. What is Data Migration? Data Migration Plan Explained دیبا میرشفیعیدیبا میرشفیعیMon, 01 Jun 2026 22:06:38 +0330