فصل ۱۵ بر اهمیت معماری نرم افزار تاکید مجدد دارد و میگوید معماری تصمیماتی بنیادی برای ساختار یک نرم‌افزار است که میتواند نقش مهمی در کاهش هزینه‌های توسعه و نگهداری داشته باشد. در این فصل به کپسوله سازی هم اشاره‌ی ویژه‌ای شده است که کپسوله سازی را کلیدی ترین اصل یک معماری خوب میداند زیرا بخش‌های سیستم میتوانند تغییر پیدا کنند بدون اینکه به بقیه‌ی اجزای سیستم آسیبی وارد شود. این فصل همچنین به بررسی سبک های مختلف معماری، مانند معماری لایه ای، معماری شش ضلعی، و معماری میکروسرویس می پردازد و مبادلات بین آنها را مورد بحث قرار می دهد. به طور کلی، فصل 15 یک نمای کلی از اهمیت معماری در توسعه نرم افزار ارائه می دهد و توصیه هایی برای طراحی و پیاده سازی معماری نرم افزار خوب بیان میکند.
فصل ۱۶ درباره‌ی اهمیت decoupling اجزا در یک سیستم صحبت میکند؛ به این معنا که هر بخش سیستم مستقل از بخش‌های دیگر عملکرد داشته باشد و تغییر در یک بخش، تاثیری بر عملکرد اجزای دیگر نداشته باشد. این فصل انواع مختلف کوپلینگ، مانند کوپلینگ زمانی، مکانی و منطقی را مورد بحث قرار می دهد و توصیه های عملی برای کاهش وابستگی بین اجزا ارائه می دهد. در فصل‌های قبلی راجب اصل interface segregation صحبت شد و این اصل میتواند به کم کردن وابستگی‌ها کمک کند. به طور کلی، این فصل یک نمای کلی از اهمیت استقلال در معماری نرم افزار ارائه می دهد و میگوید Decoupling انعطاف پذیری سیستم را افزایش میدهد و توسعه و نگهداری را آسان تر میکند.
فصل ۱۷ به توصیف اهمیت و چگونگی ارتباط و تعیین مرز بین بخش‌هایی از نرم‌افزار با دنیای بیرون میپردازد. بایستی مرزهای مشخصی بین نرم‌افزار و محیط بیرون تعریف کنیم و همچنین برای مرزها interface تعریف کنیم. میتوانیم از اصل Dependency Inversion برای مدیریت وابستگی‌ها استفاده کنیم. در نهایت باید از درست بودن این مرزها و پایدار بودنشان اطمینان حاصل کرد.این فصل راهکارهایی برای مدیریت این ارتباطات و تعاملات ارائه میدهد که در نهایت سیستم قابل نگهداری تر میشود.
فصل ۱۸ بر اهمیت درک و تعریف مرزهای بین اجزا در یک سیستم نرم افزاری تمرکز دارد و انواع مرزها را مورد بحث قرار میدهد. از جمله componentها، thread ها، فرآیندهای محلی و سرویس‌ها. این فصل توصیه بر به حداقل رساندن عبور از مرزها در یک سیستم دارد. هر چه اینکار بهتر انجام شود معماری خوبی خواهیم داشت و با تعریف مرزهای واضح و مشخص میتوانیم یک سیستم انعطاف پذیر، مقیاس پذیر و قابل نگهداری داشته باشیم.
فصل ۱۹ در مورد مفهوم سیاست ها در سیستم های نرم افزاری و اهمیت سازماندهی موثر آنها در یک معماری بحث می کند. سیستم های نرم افزاری اساساً بیانیه های خط مشی هستند و چگونگی تبدیل ورودی ها به خروجی ها را توصیف می کنند. معماری خوب شامل جداسازی و گروه بندی مجدد سیاست ها بر اساس ویژگی های تغییر آنهاست و مولفه ها بر اساس سطحشان طبقه بندی می شوند و سیاست های ورودی/خروجی پایین ترین سطح هستند. معماری مناسب سیاست های سطح بالا را از جزئیات سطح پایین جدا می کند و تاثیر تغییرات را کاهش می دهد. در اصل، فصل بر اهمیت سیاست‌های ساختاری در معماری نرم‌افزار برای افزایش قابلیت نگهداری و انعطاف‌پذیری تاکید میکند و کاربرد اصول مختلف طراحی نرم‌افزار را در دستیابی به این اهداف برجسته میکند.
فصل ۲۰ بر اهمیت جداسازی قوانین تجاری از بقیه سیستم تاکید می کند. قوانین کسب و کار سیاست ها و رویه هایی هستند که بر رفتار سیستم حاکم هستند و اغلب منحصر به یک تجارت یا صنعت خاص هستند. آنها باید جدا از رابط کاربری، پایگاه داده و سایر نگرانی های زیرساختی نگهداری شوند تا اصلاح آنها بدون تأثیرگذاری بر سایر بخش های سیستم آسان تر شود. این فصل انواع مختلف قوانین تجاری را نیز مورد بحث قرار می دهد؛ قوانین باید به طور ساده و قابل فهم نگهداری شوند. با رعایت این موارد اصلاح و نگهداری سیستم‌ها ساده‌تر خواهد بود.
فصل ۲۱ بر اهمیت ایجاد یک معماری واضح و قابل درک برای یک سیستم نرم افزاری تاکید می کند. یک معماری خوب باید ساده، واضح و قابل درک باشد، همچنین باید انعطاف پذیر و سازگار با نیازهای متغیر باشد. این فصل مفهوم « screaming architecture » را معرفی میکند، چنین معماری‌ایی هدف خود را به وضوح بیان میکند، درک و هدایت آن آسان است و انعطاف‌پذیر و سازگار است. این فصل چندین نمونه از ظاهر چنین معماری را در عمل ارائه میکند، مانند استفاده از قراردادهای نام‌گذاری واضح و سازگار، و ایجاد یک معماری مدولار و انعطاف‌پذیر. با پیروی از این اصول، توسعه دهندگان می توانند سیستم هایی ایجاد کنند که درک، اصلاح و نگهداری آنها در طول زمان آسان باشد.
فصل ۲۲ مفهوم رویکرد معماری تمیز برای توسعه نرم افزار را معرفی می کند. جداسازی concern ها و وارونگی وابستگی دو مولفه‌ی مهم در تولید چنین نرم‌افزاری هستند. معماری تمیز به جداسازی بین منطق بیزینس و جزئیات پیاده سازی تاکید دارد. این فصل مروری بر لایه‌ها و مؤلفه‌هایی که یک معماری تمیز را تشکیل می‌دهند، شامل موجودیت‌ها، یوز کیس‌ها، اینترفیس‌ها و لایه‌های زیرساخت ارائه میکند. همچنین به اهمیت ایجاد مرز مشخص بین لایه‌ها و استفاده از تزریق وابستگی برای مدیریت وابستگی‌ها بین اجزا میپردازد.
فصل ۲۳ یک الگوی طراحی را ارائه میدهد؛ الگوی Object Humble یک اصل طراحی است که رفتارهایی که آزمایش سخت دارند را از رفتارهای آزمایش آسان جدا می کند. این کار را با ایجاد دو ماژول انجام می دهد: View، که شی فروتن است، ارائه داده ها را به شیوه ای ساده مدیریت می کند. Presenter که شی قابل آزمایش است و مسئول قالب بندی و آماده سازی داده ها برای View است. این الگو برای افزایش تست‌پذیری نرم‌افزار، به‌ویژه در مرزهای معماری استفاده میشود. با جدا کردن رفتارهای پیچیده یا آزمایش کردن سخت از رفتارهایی که به راحتی قابل آزمایش هستند، آزمایش را ساده می کند.
فصل ۲۴ مرزهای جزئی را مورد بحث قرار میدهد که جایگزینی ارزان‌تر برای مرزهای کامل معماری هستند. معمولا ایجاد مرزهای کامل کاری زمانبر و هزینه‌بر است. معماران ممکن است یک مرز جزئی را زمانی اجرا کنند که هزینه یک مرز کامل بسیار زیاد باشد. این فصل همچنین استفاده از مرزهای جزئی را در عمل پوشش می دهد، از جمله مثال هایی از نحوه اجرای آنها و نحوه آزمایش آنها. به طور کلی، یک نمای کلی از مرزهای جزئی و استفاده از آنها در معماری نرم افزار ارائه می شود.
فصل ۲۵ اهمیت جداسازی concern ها در معماری نرم افزار را مورد بحث قرار می دهد و مفهوم لایه ها را معرفی می کند؛ لایه‌ها راهی برای سازماندهی کد به گروه‌هایی با عملکردهای مرتبط هستند که هر لایه مسئولیت خاصی دارد. نحوه تعامل لایه ها با یکدیگر و مرزها در معماری نرم یک امر بسیار مهمی است. نمونه هایی از نحوه تعریف API و مدیریت وابستگی بین لایه ها نیز گفته شده است. همچنین اصل وارونگی وابستگی (DIP) را که پیش از این آشنا شدیم، نمونه هایی از نحوه اعمال آن در عمل را ارائه می دهد. به طور کلی، این فصل یک نمای کلی از لایه ها و مرزها در معماری نرم افزار ارائه می دهد.
فصل ۲۶ اهمیت داشتن یک جزء اصلی را در هر سیستم نرم افزاری که اجزای دیگر را ایجاد، هماهنگ و نظارت می کند، بحث می کند. این جزء اصلی وظیفه‌ی مدیریت جریان کنترل و داده‌ها بین سایر اجزا را بر عهده دارد. جزء اصلی بایستی ساده نگه داشته شود. در این فصل نمونه هایی از نحوه طراحی جزء اصلی و نحوه مدیریت وابستگی های آن و نحوه‌ی استفاده از interfaceها برای جدا کردن جزء اصلی از سایر اجزا ارائه شده است. آزمایش این جزء اصلی بسیار مهم است و آزمون‌هایی در این باره در کتاب ارائه شده است.
فصل ۲۷ استفاده از خدمات در معماری نرم افزار را توضیح میدهد. همه‌ی سرویس‌ها از نظر معماری مهم نیستند و معماری یک سیستم با مرزهایی تعریف می شود که خط مشی سطح بالا را از جزئیات سطح پایین جدا می کند و از قانون وابستگی پیروی می کند. طراحی خدماتی که از نظر معماری مهم هستند از اهمیت برخوردارند. به نحوه‌ی استفاده از خدمات برای جداسازی عملکردها در بین فرآیندها و پلتفرم ها هم در این فصل اشاره شده است.
فصل ۲۸ نقش تست را در معماری نرم افزار مورد بحث قرار می دهد. تست‌ها بخشی از سیستم هستند و مانند هر بخش دیگری از سیستم در معماری شرکت می‌کنند. همچنین انواع مختلف آزمون‌ها، مانند آزمون‌های واحد، آزمون‌های یکپارچه‌سازی، آزمون‌های پذیرش، آزمون‌های عملکردی و غیره وجود دارند. این فصل بر اهمیت طراحی برای آزمایش پذیری تأکید می کند و مثال هایی از نحوه انجام این کار ارائه می دهد. Testing API مجموعه‌ای از توابع و کلاس‌ها است که به تست‌ها اجازه میدهد با سیستم تحت آزمایش تعامل داشته باشند. تست ها جزئی از سیستم هستند و یک معماری خوب باید قابل آزمایش باشد.
فصل ۲۹ بر استفاده از اصول معماری در نرم‌افزارها و سیستم‌های عامل تعبیه شده توصیه میکند. در معماری سیستم‌های تعبیه شده باید به وجود محدودیتهای منابع توجه داشت. قابل تست بودن معماری در اینجا نیز تاکید شده است که به حداقل رساندن وابستگی‌های اجزای سیستم به این امر کمک میکند. این فصل بر ماژولار بودن طراحی نیز تاکید مجدد دارد زیرا میتواند به کاهش پیچیدگی سیستم کمک کند و در نهایت تست پذیری افزایش پیدا کند.
