کتاب "معماری تمیز" - خلاصه فصل پنجم

کتاب "معماری تمیز" نوشته رابرت سی. مارتین به اصول و عملیات معماری نرم‌افزار می‌پردازد. بخشی با عنوان "PART V: Architecture" از صفحه 133 شروع می‌شود و شامل چندین فصل است که به بررسی هسته اصلی ، مرزها و کامپوننت های معماری نرم‌افزارمی پردازد.فصل 15: معماری چیست؟-توسعه، استقرار، عملیات و نگهداری: معماری نقش حیاتی در این جنبه‌های نرم‌افزار دارد. اطمینان حاصل می‌کند که سیستم قابل نگهداری، قابل مقیاس‌پذیری است و به طور کارآمد استقرار می‌یابد.-نگه داشتن گزینه‌ها: یک معماری خوب در اتخاذتصمیمات عجله نمی‌کند، به ویژه آنهایی که بعداً سخت تغییر می‌کنند.-استقلال از زیرساخت: معماری نباید به طور زیادی به سکو یا پلتفرم‌های خاص وابسته باشد.-آدرس‌دهی فیزیکی در مقابل آدرس‌دهی منطقی: نویسنده بر اهمیت جدا کردن آدرس‌دهی فیزیکی داده از ساختار منطقی آن تأکید می‌کند.فصل 16: استقلال-موارد استفاده: معماری باید مستقل از موارد استفاده خاص باشد، امکان انعطاف‌پذیری و مقیاس‌پذیری را فراهم می‌کند.-عملیات، توسعه و استقرار: اینها باید فرآیندهای مستقل باشند، نه به شدت به هم وابسته.-لایه‌ها و موارد استفاده را جدا کردن: معماری باید امکان جدا کردن دغدغه ها را فراهم کند، معماری هنر جدا کردن لایه‌های مختلف و موارد استفاده است.فصل 17: تعریف مرزها - یک مطالعه موردی: تعریف مرزها و جداسازی ها در شرکت FitNesse و چگونگی تعریف مرزها سیستم نرم‌افزاری آن که موجب موفقیت پروژه شد.-معماری افزونه: معماری باید امکان اضافه یا حذف افزونه‌ها را بدون تأثیر بر سیستم اصلی فراهم کند.-ورودی ها و خروجی ها: اینها باید به عنوان رابط‌های خارجی در نظر گرفته شوند و معماری باید طراحی شود تا آنها را به طور کارآمد مدیریت کند.فصل 18: تشریح مرزها-عبور از مرز: معماری باید تعریف کند چگونه داده‌ها کنترل می شوند و از مرزها عبور می کنیم و به لایه های مختلف می رویم.-کامپوننت های استقرار: این کامپوننت ها هستند از استقرار تا تولید را مدیریت می کنند. طراحی آنها باید مبتنی بر مقیاس‌پذیری و اطمینان بخشی از استقرار صحیح باشد.-درخواستها، پردازش ها و سرویس ها: معماری باید همزمانی و توزیع درخواستها را به طور کارآمد مدیریت کند.فصل 19: سیاست و سطح-سطح: کامپوننت های مختلف در معماری می‌توانند سطوح مختلفی از اهمیت و ثبات داشته باشند.-سیاست: معماری باید سیاست‌ها یا قوانینی را تعریف کند که کامپوننت ها در هر سطحی باید به آنها پایبند باشند.فصل 20: قوانین تجاری-موجودیت ها و موارد استفاده: معماری باید به طور واضح موجودیتها و موارد استفاده‌ای که در آنها در سیستم دارند را تعریف کند.-مدل‌های درخواست و پاسخ: این مدل‌ها تعریف می‌کنند چگونه داده‌ها از سیستم درخواست و به آن پاسخ داده می‌شود.فصل 21: مانیفست معماری -موضوع یک معماری: معماری باید به طور واضح هدف و عملکرد سیستم را منتقل کند.-چارچوب‌ها ابزار هستند: در حالی که چارچوب‌ها می‌توانند در توسعه کمک کنند، آنها نباید معماری را مشخص کنند.فصل 22: لایه‌ها و مرزها-بازی شکار وامپوس: از این بازی به عنوان یک مثال نمادین برای نیافادن در تله ، گلوگاه ها ، چاله ها و خطرات طراحی اشتباه می توان بهر جست لذا اصول این بازی برای پیاده اصول معماری می تواند استفاده می‌شود.-اصل عبور از جریان‌ها: چالش‌های ترکیب جریان‌های کنترل و داده را بررسی می‌کند.-اصل جدا کردن جریان‌ها: راه‌حل‌هایی را برای جدا کردن این جریان‌ها ارائه می‌دهد.فصل 23: اصلی‌ترین مؤلفه-بخش مهم: کامپوننت اصلی را به عنوان یک بخش مهم در معماری توصیف می‌کند.-جداسازی هسته: تأکید بر نگه داشتن کامپوننت اصلی جدا از قوانین و مقررات کسب وکاری دارد.-رویکرد افزونه محور: مؤلفه اصلی را به عنوان یک افزونه به برنامه معرفی می‌کند.فصل 24: خدمات، بزرگ و کوچک- معماری سرویس: بررسی می‌کند که چه چیزی یک معماری سرویس را تشکیل می‌دهد و چه منافعی دارد.- راهکار شی گرایی: راه‌حل‌های شیء‌گرا برای حل چالش‌های معماری مناسب است.فصل 25: آزمون-طراحی مبتنی بر آزمون: تأکید بر ایجاد سیستم‌هایی که آسان تست شوند.آزمون: مفهوم آزمون‌ها به عنوان کامپوننت ‌های سیستم را معرفی می‌کند.فصل 26: معماری تمیز-آزمون App-titude: یک آزمون برای ارزیابی معماری سیستم‌های تعبیه شده را معرفی می‌کند.-گلوگاه سخت‌افزاری: چالش‌ها در سخت افزارهای مورد استفاده را بررسی می‌کند.فصل 27: پایگاه داده یک جزئیات است-پایگاه‌های داده رابطه‌ای: به بررسی گسترش این پایگاه‌های داده در سیستم‌های نرم‌افزاری می‌پردازد.-سناریوهای فرضی: سوالاتی مانند "اگر هیچ دیتا بیسی وجود نداشت چه می‌شد؟" را مطرح می‌کند.فصل 28: وب یک جزئیات استپشرو و بی‌پایان: بررسی می‌کند چگونه تکنولوژی‌های وب به طور چرخشی تغییر می‌کنند.-وب به عنوان یک جزئیات: مدعی می‌شود که وب نباید طراحی معماری را مشخص کند.فصل 29: چارچوب‌ها جزئیات هستند-ریسک‌های چارچوب‌ها: بررسی می‌کند خطرات احتمالی از وابستگی زیاد به چارچوب‌های خاص.-چارچوب‌ها به عنوان ابزار: تأکید بر در نظر گرفتن چارچوب‌ها به عنوان ابزار و نه به عنوان عناصر اصلی معماری.در خلاصه، این فصل‌ها از "معماری تمیز" بر اهمیت حفظ مرزهای واضح و در نظر گرفتن کامپوننتهای خارجی از جمله پایگاه‌های داده، تکنولوژی‌های وب یا چارچوب‌ها به عنوان جزئیات تأکید می‌کند. منطق و قوانین تجاری کسب و کاری باید مستقل باقی بمانندو معماری تمیز باید تضمین کننده قابلیت مقیاس پذیری، نگهداری ، پایداری و از همه مهمتر تغییرپذیری و توسعه باشد.