کتاب صوتی ستون فقرات نرم‌افزار: معماری و طراحی هسته برای سیستم‌های پایدار

🎓 دوره آموزشی جامع

📚 اطلاعات دوره

عنوان دوره: دوره ستون فقرات نرم‌افزار: معماری و طراحی هسته برای سیستم‌های پایدار

موضوع کلی: اصول توسعه نرم‌افزار

موضوع میانی: طراحی بنیادین سیستم‌های نرم‌افزاری

📋 سرفصل‌های دوره

• 1. مقدمه: چرا ستون فقرات نرم‌افزار اهمیت دارد؟
• 2. استعاره ستون فقرات: هسته پایدار در برابر جزئیات بی‌ثبات
• 3. بدهی فنی: هزینه پنهان طراحی ضعیف
• 4. معماری در مقابل طراحی: تفاوت‌ها و هم‌پوشانی‌ها
• 5. اهداف اصلی یک طراحی خوب: نگهداری، آزمون‌پذیری و انعطاف‌پذیری
• 6. سیاست‌ها و جزئیات: تفکیک منطق کسب‌وکار از تکنولوژی
• 7. چرخه حیات نرم‌افزار و نقش معماری در آن
• 8. پارادایم‌های برنامه‌نویسی: ساخت‌یافته، شیءگرا و تابعی
• 9. اصول اولیه تفکر معمارانه
• 10. هزینه تغییر و چگونگی کاهش آن با طراحی مناسب
• 11. اصول SOLID: سنگ بنای طراحی پایدار
• 12. اصل مسئولیت واحد (SRP): تعریف و اهمیت
• 13. SRP در عمل: شناسایی و تفکیک مسئولیت‌ها
• 14. نقض SRP و عواقب آن: کلاس‌های همه‌کاره
• 15. اصل باز/بسته (OCP): توسعه بدون تغییر کد موجود
• 16. استراتژی‌ها برای پیاده‌سازی OCP: پلاگین‌ها و انتزاع
• 17. اصل جایگزینی لیسکوف (LSP): وراثت صحیح
• 18. شناسایی و اصلاح نقض LSP در سلسله‌مراتب کلاس‌ها
• 19. اصل تفکیک واسط‌ها (ISP): جلوگیری از واسط‌های سنگین
• 20. اصل وارونگی وابستگی (DIP): ستون فقرات استقلال
• 21. جزئیات به انتزاعات وابسته‌اند، نه برعکس
• 22. وارونگی کنترل (IoC) و تزریق وابستگی (DI)
• 23. انسجام (Cohesion): همه چیز در جای خود
• 24. وابستگی (Coupling): کاهش اتصالات مضر و خطرناک
• 25. قانون دیمیتر (Law of Demeter): کمتر صحبت کن
• 26. اصل DRY (Don't Repeat Yourself): مدیریت دانش تکراری
• 27. اصل YAGNI (You Ain't Gonna Need It): پرهیز از پیچیدگی زودهنگام
• 28. اصل KISS (Keep It Simple, Stupid): قدرت سادگی
• 29. انتزاع (Abstraction): پنهان‌سازی پیچیدگی
• 30. کپسوله‌سازی (Encapsulation): حفاظت از داده و رفتار
• 31. کامپوننت‌ها: واحدهای استقرار
• 32. اصول طراحی کامپوننت: وابستگی و پایداری
• 33. اصل وابستگی‌های غیرچرخه‌ای (Acyclic Dependencies Principle)
• 34. اصل وابستگی‌های پایدار (Stable Dependencies Principle)
• 35. اصل انتزاعات پایدار (Stable Abstractions Principle)
• 36. معماری چیست؟ هنر ترسیم مرزها
• 37. مرزها (Boundaries): خطوط جداکننده در معماری
• 38. عبور از مرزها: ساختارهای داده و انتقال اطلاعات
• 39. معماری لایه‌ای (Layered Architecture): تفکیک کلاسیک دغدغه‌ها
• 40. معماری پیاز (Onion Architecture): هسته در مرکز
• 41. معماری شش‌ضلعی (Hexagonal Architecture): پورت‌ها و آداپتورها
• 42. معماری پاک (Clean Architecture): تلفیق اصول طراحی
• 43. قانون وابستگی در معماری پاک
• 44. موجودیت‌ها (Entities): قوانین کسب‌وکار سطح بالا
• 45. موارد استفاده (Use Cases): سیاست‌های برنامه
• 46. واسط‌های ورودی و خروجی (Interface Adapters)
• 47. کنترلرها، ارائه‌دهنده‌ها و Gatewayها
• 48. فریم‌ورک‌ها و درایورها: لایه بیرونی
• 49. Humble Object Pattern: جداسازی منطق قابل تست
• 50. پایگاه داده به عنوان یک جزئیات
• 51. رابط کاربری (UI) به عنوان یک جزئیات
• 52. وب به عنوان یک جزئیات
• 53. فریم‌ورک‌ها به عنوان یک جزئیات
• 54. چگونه از قفل شدن در یک فریم‌ورک جلوگیری کنیم
• 55. الگوی مخزن (Repository Pattern) برای جداسازی دیتابیس
• 56. الگوی واحد کار (Unit of Work Pattern)
• 57. الگوی آداپتور (Adapter Pattern): اتصال ناسازگارها
• 58. الگوی نما (Facade Pattern): ساده‌سازی رابط‌های پیچیده
• 59. الگوی دکوراتور (Decorator Pattern): افزودن رفتار به صورت پویا
• 60. الگوی استراتژی (Strategy Pattern): کپسوله‌سازی الگوریتم‌ها
• 61. الگوی فرمان (Command Pattern) و جداسازی درخواست‌کننده از اجراکننده
• 62. جداسازی فرمان از پرس‌وجو (CQRS): مقدمه‌ای بر یک الگوی پیشرفته
• 63. رویدادنگاری (Event Sourcing): ثبت تغییرات به عنوان رویداد
• 64. معماری مبتنی بر رویداد (Event-Driven Architecture)
• 65. تکامل معماری: طراحی برای تغییر
• 66. قابلیت نگهداری (Maintainability) به عنوان یک ویژگی کلیدی
• 67. آزمون‌پذیری (Testability): نتیجه یک طراحی خوب
• 68. هرم آزمون: استراتژی تست موثر
• 69. تست واحد (Unit Testing) برای هسته منطقی سیستم
• 70. تست‌های یکپارچه‌سازی (Integration Tests) در مرزهای سیستم
• 71. تست‌های انتها به انتها (End-to-End Tests) و نقش آن‌ها
• 72. استفاده از Mock و Stub برای ایزوله کردن تست‌ها
• 73. توسعه مبتنی بر آزمون (TDD) و نقش آن در طراحی
• 74. رفکتورینگ: بهبود مستمر طراحی
• 75. تکنیک‌های رایج رفکتورینگ برای بهبود ساختار
• 76. رفکتورینگ به سمت معماری پاک
• 77. مقابله با پیچیدگی: ذاتی در مقابل تصادفی
• 78. مستندسازی معماری: چرا و چگونه؟
• 79. مدل C4 برای تجسم معماری نرم‌افزار
• 80. تصمیمات معماری و ثبت آن‌ها (ADRs)
• 81. کار با کد قدیمی (Legacy Code): استراتژی‌های بهبود
• 82. شکستن یکپارچگی: از مونولیت به میکروسرویس
• 83. معایب و مزایای میکروسرویس‌ها از دیدگاه معماری
• 84. ارتباط بین سرویس‌ها: همزمانی در مقابل ناهمزمانی
• 85. معماری و مقیاس‌پذیری (Scalability)
• 86. معماری و قابلیت اطمینان (Reliability)
• 87. سیستم‌های توزیع‌شده و چالش‌های طراحی
• 88. قضیه CAP: انتخاب بین سازگاری، دسترس‌پذیری و تحمل‌پذیری
• 89. طراحی APIهای تمیز و پایدار
• 90. قرارداد داده (Data Contract) و تکامل آن
• 91. نقش معمار نرم‌افزار در تیم Agile
• 92. معماری تکاملی و طراحی اضطراری
• 93. بازخورد و تکرار در فرآیند طراحی معماری
• 94. مطالعه موردی: طراحی یک سیستم با اصول ستون فقرات
• 95. مطالعه موردی: رفکتورینگ یک سیستم قدیمی
• 96. اشتباهات رایج در طراحی معماری و نحوه اجتناب از آن‌ها
• 97. تفکر معمارانه: فراتر از کدنویسی
• 98. ستون فقرات نرم‌افزار به عنوان یک فلسفه
• 99. جمع‌بندی نهایی: ساختن نرم‌افزارهای ماندگار