فصل 15:
معماری چیست؟ معماری به سیاست های سطح بالا یا اصول طراحی اشاره دارد که توسعه یک سیستم نرم افزاری را هدایت می کند. این پایه ای است که سیستم بر روی آن ساخته می شود و تصمیمات مربوط به رابط ها، چارچوب ها، وابستگی ها و سیستم های پایگاه داده را در بر می گیرد.
خط مشی سطح بالا باید در مورد جزئیات خاص سیستم، مانند رابط با دنیای خارج، میکروسرویس های یا چارچوب های SOA، چارچوب های تزریق وابستگی، و انتخاب سیستم پایگاه داده، ناشناس باشد. با توسعه خط مشی سطح بالا بدون تعهد به این جزئیات، می توان تصمیم گیری در مورد آنها را به تأخیر و یا تعویق انداخت و امکان جمع آوری اطلاعات بیشتر و انتخاب های آگاهانه تر را فراهم کرد. ساختار دقیق سیستم، مانند تعداد سیلندرها و هدهای روی دیسک یا داده‌های خاص ذخیره‌شده در هر سیلندر، نباید به‌صورت سخت به کد متصل شود، بلکه باید توسط خط‌مشی سطح بالا تعیین شود. خط مشی سطح بالا نباید مربوط به نوع خاصی از سیستم پایگاه داده مورد استفاده باشد، چه فایل های رابطه ای، توزیع شده، سلسله مراتبی یا مسطح .
فصل 16:
جداسازی در سطح کد منبع ممکن است برای طول عمر پروژه کافی باشد، اما اگر مشکلات استقرار یا توسعه ایجاد شود، جداسازی در سطح استقرار ممکن است ضروری باشد. جداسازی در سطح خدمات یک رویکرد رایج است، اما می‌تواند گران باشد و جداسازی درشت دانه را تشویق کند. معماری سیستم باید از موارد استفاده ای که برای آن در نظر گرفته شده است پشتیبانی کند و این باید اولین دغدغه معمار باشد.
حالت جداسازی یک سیستم احتمالا با گذشت زمان تغییر می کند و یک معمار خوب باید این تغییرات را پیش بینی و تسهیل کند. هنگام جداسازی عمودی موارد استفاده، مهم است که در برابر وسوسه جفت کردن آنها بر اساس شباهت‌ها در ساختار صفحه نمایش، الگوریتم‌ها یا پرسش‌ها و طرح‌واره‌های پایگاه داده مقاومت کنید.
فصل 17:
این بخش مفهوم معماری نرم‌افزار را مورد بحث قرار می‌دهد، که شامل ترسیم مرزهای بین عناصر نرم‌افزار برای به تعویق انداختن تصمیم‌های غیر تجاری و به حداقل رساندن منابع مورد نیاز برای توسعه و نگهداری سیستم است. هدف این است که تصمیمات مربوط به چارچوب‌ها، پایگاه‌های داده، وب سرورها، کتابخانه‌های ابزار و تزریق وابستگی را از منطق اصلی کسب‌وکار جدا نگه داریم و به آنها اجازه دهیم در مراحل بعدی بدون تأثیر قابل‌توجه اتخاذ شوند. این قسمت بر اهمیت جداسازی اجزای مختلف یک سیستم، مانند رابط‌های کاربری گرافیکی و قوانین تجاری، با مرزها تأکید می‌کند. این مرزها به مدیریت تغییرات و وابستگی‌های بین اجزا کمک می‌کند و امکان انعطاف‌پذیری و جایگزینی آسان‌تر اجزا را بدون تأثیرگذاری بر دیگران فراهم می‌کند. اصل مسئولیت منفرد و اصل وارونگی وابستگی به عنوان اصول راهنما برای ترسیم این مرزها ذکر شده است.
فصل 18:
این بخش در مورد هدف معماری داشتن فرآیندهای سطح پایین به عنوان پلاگین برای فرآیندهای سطح بالاتر، با ارتباط در سراسر مرزهای فرآیند محلی شامل فراخوانی سیستم عامل، مارشال کردن داده ها و رمزگشایی، و سوئیچ های زمینه بین پردازشی بحث می کند. حالت جداسازی در سطح استقرار استفاده می شود، که در آن اجزا به شکل باینری یا قابل استقرار، مانند یک فایل WAR یا یک فهرست، تحویل داده می شوند. وابستگی‌های کد منبع برای ایجاد گذرگاه‌های مرزی مناسب مدیریت می‌شوند، زیرا تغییرات در یک ماژول کد منبع ممکن است نیاز به تغییر یا کامپایل مجدد ماژول‌های دیگر داشته باشد. معماری یک سیستم با اجزای نرم افزاری و مرزهایی که آنها را از هم جدا می کند، تعریف می شود که می تواند اشکال مختلفی داشته باشد.
فصل 19:
Policy and Level
یک بخش تحقیقاتی است که در مورد چگونگی سیستم های نرم افزاری و اساساً بیانیه خط مشی هستند، جایی که یک برنامه کامپیوتری به عنوان توصیف دقیق خط مشی ای عمل می کند که توسط آن ورودی ها به خروجی تبدیل می شوند. این قسمت بر اهمیت جداسازی سیاست‌های سطح بالا از ورودی‌های سطح پایین تأکید می‌کند
فصل 20:
قوانین کسب و کار و قوانین حیاتی کسب و کار: قوانین تجاری، از جمله قوانین حیاتی کسب و کار، قوانین یا رویه هایی هستند که باعث ایجاد یا صرفه جویی در پول کسب و کار می شوند. آنها صرف نظر از اینکه بر روی کامپیوتر پیاده سازی شوند یا به صورت دستی اجرا شوند وجود دارند. قوانین حیاتی کسب و کار برای خود کسب و کار ضروری هستند و حتی بدون اتوماسیون نیز وجود خواهند داشت. آنها را می توان توسط یک برنامه کامپیوتری یا به صورت دستی توسط یک کارمند محاسبه کرد. موارد استفاده و قوانین خاص برنامه: موارد استفاده قوانین خاص برنامه را توصیف می کند که بر تعامل بین کاربران و موجودیت ها حاکم است. آنها رابط کاربری سیستم یا نحوه ظاهر شدن سیستم برای کاربر را توصیف نمی کنند. موارد استفاده اشیایی هستند که دارای عملکردهایی هستند که قوانین تجاری خاص برنامه را اجرا می کنند. آنها همچنین شامل داده های ورودی، داده های خروجی و ارجاع به نهادهای مربوطه می شوند. بی ربط بودن تحویل سیستم و مدیریت داده ها: موارد استفاده نحوه تحویل سیستم (وب، کلاینت ضخیم، کنسول یا سرویس) یا نحوه ورود و خروج داده ها به سیستم را مشخص نمی کند. تمرکز بر روی قوانین خاص برنامه است که بر تعامل کاربر و نهاد حاکم است.
فصل 21:
این بخش اهمیت معماری نرم‌افزاری را مورد بحث قرار می‌دهد که از موارد استفاده سیستم پشتیبانی می‌کند، مشابه اینکه چگونه پلان‌های یک ساختمان موارد استفاده آن را منعکس می‌کنند. چارچوب‌ها ابزارهای قدرتمندی هستند، اما باید با شک و تردید به آنها نگاه کرد و برای حفظ تأکید مورد استفاده در معماری، به‌طور استراتژیک از آنها استفاده کرد. معماری نباید بر اساس چارچوب باشد. فریم ورک ها ابزارهایی هستند که باید مورد استفاده قرار گیرند، نه معماری هایی که باید با آنها مطابقت داشته باشند. معماری یک سیستم به جای تمرکز بر چارچوب های مورد استفاده، باید موارد استفاده سیستم را به اشتراک بگذارد. هنگامی که برنامه نویسان جدید به مخزن منبع نگاه می کنند، باید بتوانند موارد استفاده سیستم را بدون اطلاع از جزئیات نحوه تحویل آن درک کنند.
فصل 22:
این بخش معماری های مختلفی را مورد بحث قرار می دهد که هدف آنها جداسازی نگرانی ها و استقلال از چارچوب ها است. این معماری ها شامل معماری clean، معماری شش ضلعی (همچنین به عنوان پورت ها و آداپتورها نیز شناخته می شود) و غیره است. همه آنها در هدف جداسازی قوانین تجاری از رابط های کاربر و سیستم مشترک هستند و با تقسیم نرم افزار به لایه ها به این هدف می رسند. معماری پاک، به طور خاص، بر استفاده از لایه‌ها برای جداسازی نگرانی‌ها و حفظ جزئیاتی مانند پایگاه داده و چارچوب وب در خارج تأکید می‌کند. درونی‌ترین لایه تبدیل داده‌ها را برای چارچوب‌های ماندگار انجام می‌دهد، در حالی که بیرونی‌ترین لایه از چارچوب‌ها و ابزارها تشکیل شده است. این قسمت بینش هایی در مورد این معماری ها و اصول آنها برای ساختن سیستم های نرم افزاری قوی و قابل نگهداری ارائه می دهد.
فصل 23:
این بخش استفاده از الگوی Humble Object در معماری نرم افزار را برای افزایش تست پذیری سیستم ها مورد بحث قرار می دهد. این الگو در مرزهای معماری مانند بین رابط های دروازه و پایگاه داده یا بین سرویس ها اعمال می شود. با تفکیک رفتارهای قابل آزمایش و غیر قابل آزمایش به کلاس‌های مختلف، مانند Presenter و Viewدر مورد رابط‌های گرافیکی، الگوی Humble Objectامکان تست واحد را آسان‌تر می‌کند. این بخش تأکید می کند که آزمایش پذیری یک ویژگی مهم معماری های خوب است و استفاده از الگوی Humble Object به دستیابی به این هدف کمک می کند.
فصل 24:
این بخش مفهوم مرزهای معماری و استراتژی های مختلف برای اجرای آنها را مورد بحث قرار می دهد. یک رویکرد این است که به طور مستقل اجزای قابل کامپایل و قابل استقرار ایجاد کنید و آنها را با هم در یک جزء نگه دارید. سه راه ساده برای اجرای جزئی یک مرز معماری وجود دارد، اما استراتژی های بسیار دیگری نیز وجود دارد. هر رویکرد دارای هزینه ها و مزایای خاص خود است و در زمینه های خاص به عنوان یک مکان نگهدار برای یک مرز آینده مناسب است. با این حال، اگر مرز هرگز محقق نشود، پیاده سازی می تواند تنزل یابد.
فصل 25:
این بخش مفهوم مرزهای معماری در سیستم‌های نرم‌افزاری و اهمیت تشخیص زمانی که به آنها نیاز است را مورد بحث قرار می‌دهد. نویسنده از مثال یک بازی رایانه ای مبتنی بر متن برای نشان دادن مفهوم جداسازی رابط کاربری (UI) از قوانین بازی با استفاده از یک API مستقل از زبان استفاده می کند. مؤلفه UI API را به زبان انسانی مناسب برای بازارهای مختلف ترجمه می کند. قانون وابستگی به عنوان دستورالعملی برای هدایت صحیح وابستگی ها بین اجزا ذکر شده است که با استفاده از مثال MoveManagement و PlayerManagementدر بازی، ممکن است مرزهای معماری اضافی فراتر از UI، قوانین بازی و اجزای ذخیره سازی داده وجود داشته باشد. نمودار در شکل 25.7 این سناریو را به شکلی مختصر نشان می دهد. این بخش تاکید می کند که مرزهای معماری در همه جا وجود دارد و معماران باید در شناسایی و اجرای آن دقت کنند.
فصل 26:
جزء اصلی در سیستم:
مولفه اصلی پایین ترین خط مشی است و به عنوان نقطه ورود اولیه سیستم عمل می کند. مستقل از اجزای دیگر است و مسئول ایجاد تمام کارخانه ها، استراتژی ها و سایر امکانات جهانی است. شرایط و تنظیمات اولیه را تنظیم می کند، منابع خارجی را جمع آوری می کند و سپس کنترل را به خط مشی سطح بالای برنامه واگذار می کند. می توان آن را به عنوان یک افزونه برای برنامه در نظر گرفت، با قابلیت داشتن چندین مؤلفه اصلی برای پیکربندی های مختلف. وابستگی های کامپوننت اصلی باید توسط یک چارچوب تزریق وابستگی تزریق شود و پس از تزریق، Main باید آن وابستگی ها را به طور معمول بدون استفاده از چارچوب توزیع کند.
فصل 27:
خلاصه: خدمات در معماری خدمات در معماری با خود معماری یکسان نیستند، زیرا خدمات فقط فراخوانی تابع در سراسر مرزهای فرآیند و/یا پلت فرم هستند. برخی از خدمات ممکن است از نظر معماری مهم باشند، در حالی که برخی دیگر اینگونه نیستند. معماری یک سیستم با مرزهایی تعریف می شود که خط مشی سطح بالا را از جزئیات سطح پایین جدا می کند و از قانون وابستگی پیروی می کند. خدماتی که به سادگی رفتارهای برنامه را از هم جدا می کنند، کمی فراتر از فراخوانی عملکرد گران قیمت هستند و ممکن است از نظر معماری مهم نباشند. با این حال، ایجاد سرویس‌هایی که عملکردها را در بین فرآیندها و پلتفرم‌ها از هم جدا می‌کنند، چه از قانون وابستگی پیروی کنند یا نه، مزایایی دارد. علاقه در خدمات معماری قابل توجه نهفته است. فرض بر این است که مزایای فرضی خدمات تحت مالکیت و بهره برداری توسط یک تیم اختصاصی، که امکان توسعه و استقرار مستقل را فراهم می کند، مقیاس پذیر است. سیستم‌های سازمانی بزرگ را می‌توان از سرویس‌های مستقل توسعه‌پذیر و قابل استقرار با توسعه، نگهداری و بهره‌برداری بین تیم‌های مستقل ایجاد کرد. با این حال، در این باور اشتباهاتی وجود دارد. به عنوان مثال، اگر یک فیلد جدید به رکورد داده‌ای که بین سرویس‌ها ارسال می‌شود اضافه شود، هر سرویسی که در آن فیلد کار می‌کند باید تغییر کند، و آنها را به طور غیرمستقیم با یکدیگر جفت می‌کند. رابط های خدماتی رسمی تر، دقیق تر یا بهتر از رابط های تابع تعریف نمی شوند.
فصل 28:
خلاصه ای از "مرز آزمون": همه آزمون ها، صرف نظر از اندازه و نوع آنها، از نظر نقشی که در سیستم دارند، از نظر معماری معادل هستند. تست ها مانند هر جزء دیگر در معماری سیستم شرکت می کنند. تست ها را می توان بخشی از سیستم در نظر گرفت و می تواند تاثیر بسزایی در معماری سیستم داشته باشد. به عنوان مثال، تغییرات در صفحه ورود یا ساختار ناوبری می تواند باعث شکست بسیاری از تست ها شود. آزمون‌ها انواع مختلفی دارند، مانند آزمون‌های واحد، آزمون‌های ادغام، آزمون‌های پذیرش، آزمون‌های عملکردی، آزمون‌های خیار، آزمون‌های TDD، آزمون‌های BDD و آزمون‌های مؤلفه. با این حال، از منظر معماری، همه آزمون ها یکسان هستند. API آزمایشی مسئول پنهان کردن ساختار برنامه از آزمایش‌ها است و به کد تولید و آزمایش‌ها اجازه می‌دهد تا به طور مستقل بازسازی و تکامل یابند. جفت ساختاری قوی بین تست ها و کد تولید می تواند مانع از تکامل لازم هر دو جزء شود. اگر نگرانی‌هایی در مورد استقرار APIآزمایشی در سیستم‌های تولید وجود دارد، می‌توان آن را در یک جزء جداگانه و مستقل نگهداری کرد.
فصل 29:
ادعای مطرح شده توسط داگ اشمیت در قسمت خود این است که در حالی که نرم افزار فرسوده نمی شود، سیستم عامل و سخت افزار منسوخ می شوند و نیاز به اصلاحات نرم افزاری دارند. توسعه جاسازی شده نگرانی های خاصی مانند فضای حافظه محدود، محدودیت های زمان واقعی، IO محدود، رابط های کاربری غیر متعارف، و اتصالات به دنیای واقعی دارد. سخت افزار اغلب همزمان با نرم افزار و سیستم عامل توسعه می یابد و ممکن است تا زمانی که سخت افزار در دسترس نباشد، جایی برای اجرای کد وجود نداشته باشد. علاوه بر این، سخت افزار ممکن است نقص هایی داشته باشد که پیشرفت توسعه نرم افزار را بیشتر کند می کند.
توضیح ادعا: ادعای داگ اشمیت در قسمت خود این است که در حالی که نرم افزار فرسوده نمی شود، سیستم عامل و سخت افزار منسوخ می شوند و نیاز به اصلاحات نرم افزاری دارند. نگرانی های توسعه جاسازی شده: توسعه جاسازی شده نگرانی های خاصی مانند فضای حافظه محدود، محدودیت های زمان واقعی، IOمحدود، رابط های کاربری غیر متعارف، و اتصالات به دنیای واقعی دارد. سخت‌افزار اغلب همزمان با نرم‌افزار و سیستم‌افزار توسعه می‌یابد، و ممکن است تا زمانی که سخت‌افزار در دسترس نباشد، جایی برای اجرای کد وجود نداشته باشد. علاوه بر این، سخت افزار ممکن است نقص هایی داشته باشد که پیشرفت توسعه نرم افزار را بیشتر کند می کند. به طور خلاصه، این ادعا نشان می‌دهد که در حالی که نرم‌افزار به خودی خود فرسوده نمی‌شود، سفت‌افزار و سخت‌افزاری که به آن متکی است می‌تواند منسوخ شود و نیاز به اصلاحات نرم‌افزاری داشته باشد. توسعه تعبیه شده چالش های منحصر به فردی از جمله منابع محدود و نیاز به توسعه نرم افزار در کنار سخت افزار را ایجاد می کند. این عوامل می توانند بر طول عمر و مفید بودن نرم افزارهای تعبیه شده تأثیر بگذارند.
