دوره ستون فقرات نرمافزار: معماری و طراحی هسته برای سیستمهای پایدار همراه با فلشکارت آموزشی — ارائه روی فلش مموری
📚 کتاب آموزشی جامع
📚 اطلاعات کتاب
عنوان کتاب: کتاب ستون فقرات نرمافزار: معماری و طراحی هسته برای سیستمهای پایدار
موضوع کلی: اصول توسعه نرمافزار
موضوع میانی: طراحی بنیادین سیستمهای نرمافزاری
📋 سرفصلهای کتاب (100 موضوع)
- 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. جمعبندی نهایی: ساختن نرمافزارهای ماندگار
محتویات بسته آموزشی
🌐 سامانه آنلاین فلشکارت؛ مرور هدفمند و هوشمند
اکانت ارائهشده، دسترسی به نسخه تحت وب سامانه فلشکارت ویژه این دوره را فراهم میکند. این سامانه از الگوریتم زمانبندی مرور SM-2 استفاده میکند و بر اساس ارزیابی شما از میزان یادآوری هر کارت، زمان مرورهای بعدی را تنظیم میکند.
به این ترتیب، کارتهای دشوارتر میتوانند زودتر مرور شوند و برای تثبیت مطالب در حافظه، برنامه مرور متناسبتری داشته باشید.
مدتزمان معادل آموزشی بر اساس برآورد این دوره در گواهی درج میشود.
گواهی دوزبانه با استعلام آنلاین
پس از تکمیل فعالیتهای لازم و تأیید درخواست، گواهی پایان دوره به زبان فارسی و انگلیسی صادر میشود. گواهی دارای لینک اختصاصی و QR Code برای بررسی و استعلام آنلاین است.
این گواهی صرفاً بهعنوان گواهی اتمام دوره آموزشی صادر میشود و معادل مدرک دانشگاهی، آکادمیک یا مدرک رسمی مورد تأیید نهادهای دولتی نیست. صدور آن منوط به تکمیل شرایط دوره و تأیید نهایی درخواست است.
نظرات
هنوز نظری ثبت نشده است.
وارد شوید تا نظر ثبت کنید.