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