در این فصل در مورد نقش و اهمیت پایگاه داده در معماری سیستم های نرم افزاری بحث شده است. پایگاه داده، از دیدگاه معماری، به عنوان یک جزئیات تلقی میشود که در سطح عنصرهای معماری بلند مدت نیست و نباید به معماری سیستم نفوذ کند. پایگاه داده مثل یک جزئیات کوچک در مقایسه با ساختار کلی سیستم نرم‌افزاری است. ارتباط پایگاه داده با معماری سیستم نرم‌افزاری شبیه به ارتباط یک دستگیره درب با معماری خانه‌ی شماست. راحت تر بخوام بگم پایگاده داده خیلی برای معماری مهم نیست و اهمیت انچنانی ندارد. برای همین در فصل جزئیات به ان اشاره کرده است . اما مراقب باشید که پایگاه داده را با مدل داده قاطی نکنین ، استراکچری که به داده ها تو نرم افزار می دهیم بسیار مهم است و برای معماری مهم است . در کل باید حواسمان باشد که یک جزئیات سطح پایین مانند پایگاه داده وارد معماری شود و سیستم نرم افزاری مارا الوده کند.
پایگاه داده یک مکانیزم سطح پایین است که برای ذخیره کردن و دستری به داده ها استفاده می شود اما داده ها مدل داده را درست می کنند که برای معماری نرم افزار اهمیت بالایی دارند ولی پایگاه داده فقط یک وسیله یا تولز برای دسترسی به این داده هاست به همین خاطر جزو مکانیزم های سطح پایین حساب می شود.
موضوع دیگری که در این فصل صحبت شد پایگاه داده رابطه ای است . دلیل اهمیت این مدل این است که به خوبی می توانند با دیسک ها ارتباط برقرار کنند. دیسک ها برای دسترسی به داده ها بسیار کنند هستند که سیستم های مدیریت پایگاه داده از روش های مختلفی استفاده می کند تا سرعت کار را بالا ببرد . اگر از دیسک ها استفاده نکنیم و همه داده در حافظی رم ذخیره بشوند داده ها به شکل لیست های پیوندی ، درخت ها ، جداول هش و... ذخیره می شوند و با استفاده از پوینتر به ان ها دسترسی پیدا میکنیم . با گذشت زمان و پیشرفت های زیاد تکنولوژی دیسک ها منسوخ شدند و جای خود را به حافظ های موقت دادند .
درسته که پایگاه داده اهمیت بالایی دارد و به عنوان یک مکانیزم برای انتقال داده ها بین دیسک و حافظ موقت استفاده می شود ، اما نباید ان را در معماری دخیل کنیم . میشه پایگاه داده رو به صورت چداگانه از قوانین تجاوری و موارد کاربردی سیستم مدیریت کرد و وارد معماری نرم افزار نکردش.
این فصل در مورد تغییرات و نوسانات در طراحی و پیاده سازی سیستم های کامپیوتری صحبت می شود و به چگونگی توزیع قدرت پردازش می پردازد . همچنین می خواهد این را بیان کند که وب ، درست است که رابط کاربری است اما فقط یک جز از یک سیستم بزرگ تر است و نباید به عنوان تنها قسمت مهم سیستم در نظر گرفته شود. قدیم در بیشتر وقتا تمامی قدرت پردازش در یک مکان مرکزی مانند یک سرور جمع می کردند و بقیه دستگاها صرفا یک واسطه ی کاربری بودند. اما با گذشت زمان قدرت پردازش به دستگاه های محلی منتقل شد. البته چندین بار بین اینکه همه پردازش ها در یک مکان باشد یا تقسیم بشود بحث بود و مدادم جایگزین یکدیگر میشدند این دو روش.
اصلی ترین نکته که در این فصل مطرح می شود این است که وب به عنوان یک رابط کاربری فقط یکی از جزئیات سیستم است و نباید معماران در طراحی معماری نرم افزار خود قوانین کسب و کار و دیگر اجزای سطح بالا را با جزئیات فنی مانند رابط کاربری قاطی کنن و باید مستقل باشند. اگر این نکته را رعایت کنند هر وقت تغییراتی در رابطه کاربری یا تکنولوژی های مورد استفاده قرار بگیرد که بسیار هم اتفاق می افتد ، نیاز به تغیر کلی سیستم نداریم. مثلا شما بارها می بینین که شرکت های بزرگ نرم افزاری داخل و خارجی ظاهر وبسایت خود را عوض میکنند. تصور کنین که امازون یا دیجی کالا هر بار که ظاهر خود را می خواهند عوض کنند مجبور شوند کل سیستم نرم افزار خود را کامل عوض کنند چه هزینه زیادی باید پرداخت کنند .
درست است که این جدا سازی ها و محافظ از لوجیک اصلی سیستم در برابر تغییرات فنی و تکنولوژی بسیار سخت است ، اما با توجه سرعت بالای پیشرفت تکنولوژی بسیار واجب و ضروری است .
در این فصل در مورد تاثیر فریم ورک ها در معماری در نرم افزار صحبت می کند. فریم ورک ها ابزار هایی هستند که به برنامه نویسان کمک می کند تا برنامه ها را سریع تر و استاندارد تر درست کنند. فریم ورک ها بسیار قدرتمند هستند و بسیاری از ان ها رایگان در دسترس برنامه نویسان قرار گرفته اند و کمک بسیاری در تولید نرم افزار ها می کنند اما باید توجه داشته باشید که این ها به هیچ عنوان جزو معماری نرم افزار نیسند و تنها یک ابزار مناسب برای توسعه سیستم های نرم افزاری هستند. اکثر این فریم ورک ها را برنامه نویسان برای رفع مشکلات خودشان یا تیم و شرکت خودشان نوشته اند اما با توجه به کیفیت بالای ان ها و استقبال دیگران از ان در اختیار عموم قرار گرفته اند.
اما استفاده از فریم ورک ها خطرات خود را دارند . باید مراقب باشید که برنامه شما به هیچ عنوان وابسته به فریم ورک ها نشوند زیر ممکن است بعضی از قسمت های ان خوب توسعه داده نشده باشد و در روند توسعه نرم افزار شما دچار مشکل شوید. در ابتدای کار فریم ورک ها بسیار کمک کننده هستند مخصوصا زمانی که نرم افزار شما کوچک است و ویژگی های خاصی ندارد . اما زمانی که نرم افزار شما بزرگ تر و پیشرفته تر شوند فریم ورک ها پاسخگوی نیاز های شما نیستند و دست و پای شمارا میگیرند و نیاز های شما از توانایی های فریم ورک خارج می شود. همچنین امکان دارد فریم ورک ها اپدیت بشوند و ویژگی های قدیمی که شما سیستم نرم افزاری خودتونو با اون ساختین از فریم ورک حذف بشود و شما دیگر نتوانید فریم ورک خودتون را اپدیت کنین و باید از همون نسخه های قدیمی استفاده کنید که ممکن است باگ های امنیتی و.. داشته باشد و از امکانات بروز فریم ورک محروم شوید.
پس اگر بخواهیم به زبان ساده بگوییم بهترین کار این است که فریم ورک ها وابسته نشوید !!. به جای اینکه فریم ورک هارا جزوی از برنامه ی اصلی خودتون بکنین ، اون هارو تو یه قسمت جداگانه و مستقل قرار دهید و اجازه ندهید وارد کد های اصلی برنامه شما بشوند.
در این فصل در مورد یک نرم افزاری برای وبسایتی که ویدیو می فروشد صحبت می کند. یک دسته ویدیو داریم که میتوانیم به فرد یا شرکت ها بفروشیم . برای طراحی معماری نرم افزار سیستم ابتدا باید اکتر ها و یوز کیس هارا تعریف کنیم . در این مثال چهار اکتر داریم ، مدیر وبسایت ، نویسنده ویدیو ، کسی که ویدیو را میخرد و کسی که ویدیو را می بیند. پس تعریف بازیگران و یوز کیس ها معماری کامپوننت ها ایجاد میشود. معماری کامپوننت یک نقشه یا معماری از چگونگی تقسیم بندی و تعامل بخش های مختلف یک سیستم است.
مطالعه موردی روشی است برای نشان دادن چگونگی پیاده سازی قوانین و مفاهیم و در مثال های دنیای واقعی. انطعاف پذیری در تحویل به ای ن معناست که با استفاده از معماری نرم افزار خوب می شود اجزای سیستم را به هر شکل که دوست دارید تحویل دهید و با توجه نیاز ها حتی این تحویل را تغییر دهید.
در این فصل در مورد چگونگی سازماندهی کد ها در یک پروژه صحبت می کند.
ساختار لایه ای : در این روش کد ها بر اساس عملکردی فنی که دارند در لای های افقی تقسیم می شوند و کد ها مشابه از نظر وظایف در یک گروه قرار میگیرند که در عمده نرم افزار ها به سه قسمت تقسیم می شوند . لایه وب ، لایه قوانین کسب و کار و لایه دسترسی به داده ها .
ساختار بر اساس ویژگی : در این روش همانطور که از نامش پیداست کد ها بر اساس ویژگی هایشان یا عناصر اصلی تقسیم می شوند. تمامی کلاس ها یا اینتر فیس های مرتبط با یک ویژگی خاص در یک دسته قرار می گیرند.
پورت ها و اداپتر ها : در این روش به جداسای کد های معتمد بر دامنه از جزئیات فنی می پردازد. به زبان ساده تر کد های مرتبط با دامنه در داخل قرار دارند و کد های مرتبط با دنیای خارجی در خارج قرار میگیرند. در این روش کد های خارجی به داخلی وابسته باشند .
ساختار مرتبط با کامپوننت : این روش در حقیت ترکیبی از روش های قبلیست که تازه گفته شد . در این روش به ایجاد بسته های کدی مرتبط با کامپوننت های چندگانه می پردازد. این روش به سمت معماری های مبتنی بر سرویس مانند معماری میکرو سرویس میرود . این روش را نویسنده ی کتاب که اسمش یادم نیست توصیه میکند. کد ها بر اساس کامپوننت های خود پروژه تقسیم می شوند و هر کامپوننت بسته ای از کلاس ها و اینترفیس های مرتبط ب یکی ویژگی یا بخشی از سیستم را در خود دارد . این روش می تواند کد را از لایه بندی افقی و عمودی بهبود دهد.
