فصل 15: معماری چیست؟
در ابتدا تعریفی از معماری نرم‌افزار ارائه می‌دهد و توضیح می‌دهد که شامل تصمیم‌گیری‌های سطح بالا در مورد ساختار و سازمان یک سیستم نرم‌افزاری است. همچنین تأکید می‌کند که ارزش ساختار یک سیستم نرم‌افزاری از ارزش رفتار آن بیشتر است و یک معماری خوب طراحی شده می‌تواند هزینه‌های نگهداری را تا حد زیادی کاهش دهد و تغییر سیستم را در طول زمان آسان‌تر کند. وظایف یک معمار نرم‌افزار از جمله طراحی ساختار کلی سیستم، تصمیم‌گیری در مورد فناوری و ابزار‌ها و برقراری ارتباط با ذینفعان است. در ادامه اهمیت جداسازی تصمیمات خط مشی سطح بالا از جزئیات اجرای سطح پایین را مورد بحث قرار می‌دهد. توضیح می‌دهد که این جداسازی می‌تواند به کاهش هزینه تعمیر و نگهداری کمک کند و تغییر سیستم را در طول زمان آسان‌تر کند.
همچنین اشاره می‌کندکه همیشه لازم نیست درباره جزئیات خاص در اوایل فرآیند توسعه تصمیم‌گیری کنید. با باز نگه داشتن گزینه‌ها و تأخیر در تصمیم‌گیری‌ها، می‌توانید اطلاعات بیشتری را جمع‌آوری کنید و قبل از تصمیم‌گیری نهایی، آزمایش‌های مختلفی را امتحان کنید.
در آخر مثالی از اوایل دهه ۱۹۷۰ از یک سیستم حسابداری بزرگ برای اتحادیه کامیون‌داران را شرح می‌دهد. این سیستم سوابق نمایندگان، کارفرمایان و اعضا را روی یک درایو دیسک ۲۵ مگابایتی ذخیره می‌کرد. توضیح می‌دهد که ارزش استقلال دستگاه بسیار زیاد بود، زیرا به تیم اجازه می‌داد برنامه‌هایی بنویسند بدون اینکه بدانند یا اهمیت بدهند از کدام دستگاه استفاده می‌شود. این تیم می‌تواند آن برنامه‌ها را با استفاده از یک چاپگر خط محلی متصل به رایانه آزمایش کند و سپس به سیستم عامل بگوید که روی نوار مغناطیسی «چاپ» کند و صد‌ها هزار فرم را اجرا کند. این پاراگراف تأکید می‌کند که تیم تصمیم‌گیری در مورد استفاده از دستگاه را به تعویق انداخت و خط مشی (دستگاه) را از جزئیات (قالب‌بندی سوابق نام و آدرس) جدا کرد.
فصل 16 : استقلال
این فصل بر اهمیت استقلال در معماری نرم افزار تاکید می کند. معماری باید از use case و بهره برداری از سیستم ، نگهداری سیستم، توسعه و استقرار سیستم پشتیبانی کند. باید use case را به وضوح نشان دهد و از هدف سیستم پشتیبانی کند. معماری همچنین باید توان عملیاتی و زمان پاسخ دهی بالایی داشته باشد و حالت های مختلف عملکرد را در اختیار داشته باشد. این باید اقدامات مستقل توسط تیم های مختلف در محیط توسعه را تسهیل کند. علاوه بر این، معماری باید استقرار آسان را بدون پیکربندی دستی امکان پذیر کند. جداسازی لایه ها و موارد استفاده برای دستیابی به استقلال بسیار مهم است، اما تمایز بین تکرار واقعی و تکراری تصادفی مهم است. حالت های مختلف جداسازی، مانند سطح منبع، سطح استقرار و سطح سرویس، بر اساس نیازهای سیستم قابل استفاده است. نویسنده همچنین چالش ها و هزینه های مرتبط با جداسازی سطح خدمات را مورد بحث قرار می دهد و یک رویکرد انعطاف پذیر را پیشنهاد می کند. آنها اهمیت یک معماری خوب را برجسته می کنند که به سیستم اجازه می دهد از یکپارچه به واحدها یا خدمات مستقل قابل استقرار تکامل یابد و بالعکس. نویسنده با بیان اینکه حالت جداسازی یک سیستم احتمالاً در طول زمان تغییر می کند، نتیجه گیری می کند و یک معمار خوب این تغییرات را پیش بینی و تسهیل می کند.
فصل 17 : خط مرزی :خطوط طراحی
این فصل بر اهمیت ترسیم مرزها در معماری نرم افزار تاکید می کند. مرزها برای جدا کردن عناصر نرم افزار و جلوگیری از داشتن دانش بیش از حد در مورد یکدیگر عمل می کنند. تصمیمات زودهنگام، مانند انتخاب چارچوب ها یا پایگاه های داده، می تواند منجر به جفت شدن و افزایش تلاش برای توسعه شود. این فصل نمونه‌هایی از شرکت‌هایی را ارائه می‌دهد که به دلیل تصمیم‌های زودهنگام با پیامدهای منفی مواجه شدند، و همچنین نمونه‌ای از معماری موفقی که تصمیم‌گیری‌ها را به تعویق انداخت و در زمان و تلاش صرفه‌جویی کرد.
این فصل همچنین اهمیت تمایز بین چیزهایی که مهم هستند و چیزهایی که مهم نیستند، مانند رابط کاربری گرافیکی و قوانین کسب و کار، یا پایگاه داده و قوانین تجاری را برجسته می کند. رابط کاربری گرافیکی و قوانین تجاری باید با یک مرز از هم جدا شوند و رابط کاربری گرافیکی افزونه ای است که می تواند به راحتی با رابط های مختلف جایگزین شود. این معماری پلاگین مقیاس پذیری و نگهداری را امکان پذیر می کند.
رابطه بین اجزاء باید نامتقارن باشد و ماژول‌های خاصی نسبت به سایرین مصون باشند. مرزها باید در جایی ترسیم شوند که محور تغییر وجود دارد، و اصل مسئولیت واحد باید برای تعیین محل ترسیم مرزها اعمال شود. این فصل تاکید می کند که ورودی و خروجی (IO) یک سیستم، مانند یک رابط کاربری گرافیکی، نباید به عنوان خود سیستم اشتباه گرفته شود. قوانین تجاری اصلی سیستم باید از IO جدا شود و پایگاه داده باید به عنوان ابزاری در نظر گرفته شود که قوانین تجاری می توانند به طور غیر مستقیم از آن استفاده کنند. این فصل راهنمایی هایی در مورد چگونگی ترسیم موثر مرزها بین این مؤلفه ها ارائه می دهد.
فصل 18: تشریح خط مرزی
این فصل بر اشکال مختلف مرزها در معماری نرم افزار از جمله مرزهای فیزیکی و منطقی تمرکز دارد. اهمیت مدیریت وابستگی‌های کد منبع و جداسازی اجزا برای افزایش انعطاف‌پذیری، سهولت توسعه، آزمایش و استقرار را برجسته می‌کند. این فصل همچنین انواع مختلف مرزها مانند گذرگاه های مرزی، یکپارچه ها، اجزای استقرار، رشته ها، فرآیندهای محلی و خدمات را مورد بحث قرار می دهد. این بر نیاز به در نظر گرفتن الزامات خاص سیستم هنگام برقراری ارتباط در سراسر مرزها تأکید می کند، زیرا هزینه و تأخیر ارتباط می تواند متفاوت باشد.
فصل 19: خط مشی و سطح
این فصل بر نیاز به تجزیه خط مشی یک برنامه به بیانیه های کوچکتر و سازماندهی دقیق آنها بر اساس نحوه تغییر آنها تأکید می‌کند. وابستگی بین اجزاء باید بر اساس سطح آنها تعیین شود، با اجزای سطح پایین بسته به اجزای سطح بالا. این رویکرد به جداسازی سیاست‌های سطح بالا از سیاست‌های ورودی/خروجی سطح پایین کمک می‌کند و تأثیر تغییر را کاهش می‌دهد. این فصل همچنین چندین اصل را ذکر می‌کند که معماری نرم‌افزار خوب را راهنمایی می‌کند، از جمله اصل مسئولیت منفرد، اصل باز-بسته، اصل بسته مشترک، اصل وارونگی وابستگی، اصل وابستگی‌های پایدار، و اصل انتزاعات پایدار.
فصل 20: قوانین کسب و کار
این فصل مفهوم قوانین کسب و کار و اهمیت آنها در پس انداز یا کسب درآمد برای یک کسب و کار را مورد بحث قرار می دهد. انواع مختلفی از قوانین تجاری وجود دارد، از جمله قوانین تجاری حیاتی که بدون توجه به اتوماسیون وجود دارند و مواردی را استفاده می کنند که عملکرد یک سیستم خودکار را تعریف و محدود می کنند. موجودیت ها اشیایی را نشان می دهند که قوانین تجاری حیاتی را در بر می گیرند و بر روی داده های تجاری حیاتی عمل می کنند. موارد استفاده، از سوی دیگر، قوانین تجاری خاص برنامه را توصیف می کنند و تعامل بین کاربران و موجودیت ها را کنترل می کنند. توجه به این نکته ضروری است که موارد استفاده رابط کاربری سیستم را توصیف نمی کنند. مدل‌های درخواست و پاسخ در موارد استفاده برای مدیریت داده‌های ورودی و خروجی استفاده می‌شوند و باید مستقل از هر چارچوب یا رابط کاربری خاصی باشند. این فصل بر لزوم جدا ماندن قوانین تجاری از سایر نگرانی‌ها و مستقل‌ترین و قابل استفاده‌ترین کد در سیستم تأکید می‌کند.
فصل 21: معماری شگفت انگیز
این فصل بر اهمیت طراحی معماری که با موارد استفاده خاص یک برنامه همسو باشد، به جای اینکه صرفاً بر اساس چارچوب ها باشد، تأکید می کند. آنها استدلال می‌کنند که چارچوب‌ها را باید به‌عنوان ابزاری برای استفاده به‌جای پایه‌ی معماری در نظر گرفت. علاوه بر این، نویسنده پیشنهاد می کند که تصمیم گیری در مورد نحوه ارائه یک برنامه از طریق وب باید به تعویق بیفتد، زیرا نباید معماری را دیکته کند. فصل با بیان این که یک معماری خوب باید سیستم و موارد استفاده از آن را اولویت بندی کند، به جای چارچوب های به کار گرفته شده، به پایان می رسد.
فصل 22: معماری تمیز
The Clean Architecture یک معماری نرم افزاری است که بر جداسازی نگرانی ها و ایجاد سیستم هایی مستقل از چارچوب ها و عناصر خارجی تمرکز دارد. این شامل چهار لایه است: موجودیت ها، موارد استفاده، آداپتورهای رابط، و چارچوب ها/درایورها. این معماری از قانون وابستگی پیروی می‌کند، که بیان می‌کند که وابستگی‌های کد منبع فقط باید به سمت سیاست‌های سطح بالاتر به سمت داخل باشند. این رویکرد سیستم ها را قادر می سازد تا به راحتی آزمایش شوند و با تغییرات در رابط کاربری، پایگاه داده یا سایر عناصر خارجی سازگار شوند.
فصل 23: presenter و شی Humble
این فصل مفهوم ارائه‌دهنده و اشیاء Humble را به عنوان راهی برای شناسایی و محافظت از مرزهای معماری معرفی می‌کند. الگوی Object Humble یک الگوی طراحی است که رفتارهای آزمون سخت را از رفتارهای آسان برای آزمایش جدا می کند. رفتارها را به دو ماژول یا کلاس تقسیم می‌کند: شی Humble، که شامل رفتارهای آزمایش‌شدنی است، و شی قابل آزمایش، که شامل رفتارهای آزمایش‌پذیر حذف‌شده است. در زمینه رابط‌های کاربری گرافیکی، View شیء Humbleی است که آزمایش آن سخت است، در حالی که Presenter شیء قابل آزمایشی است که داده‌های برنامه را می‌پذیرد و آن را برای ارائه قالب‌بندی می‌کند. جداسازی رفتارها به بخش‌های آزمایش‌پذیر و غیرقابل آزمایش، اغلب یک مرز معماری را مشخص می‌کند. نمونه‌های دیگر از مرزهای معماری شامل دروازه‌های پایگاه داده، نقشه‌برداران داده و شنوندگان خدمات است. استفاده از الگوی Object Humble در مرزهای معماری، آزمایش پذیری سیستم را افزایش می دهد.
فصل 24: مرزهای جزئی
این فصل رویکردهای مختلفی را مورد بحث قرار می دهد که معماران می توانند در هنگام ایجاد مرزهای معماری اتخاذ کنند. این نشان می دهد که در برخی موارد، ایجاد یک مرز کامل می تواند گران و زمان بر باشد. در چنین شرایطی، معماران ممکن است انتخاب کنند که یک مرز جزئی را به عنوان یک مکان نگهدار برای یک مرز بالقوه آینده اجرا کنند. این شامل نگه داشتن تمام اجزای ضروری با هم در یک کامپوننت است، حتی اگر بتوان آنها را به طور مستقل کامپایل و مستقر کرد. در حالی که این رویکرد بار اداری را کاهش می دهد، همچنین خطر عبور وابستگی ها از مرزها را در طول زمان به همراه دارد.
از طرف دیگر، معماران می توانند از ساختارهای ساده تری مانند الگوی استراتژی یا الگوی نما استفاده کنند. این الگوها سطح پایه ای از جداسازی را فراهم می کنند اما ممکن است مشتری را به طور کامل از پیاده سازی جدا نکنند. این فصل تاکید می کند که معماران باید هزینه ها و مزایای هر رویکرد را به دقت در نظر بگیرند و تصمیم بگیرند که آیا یک مرز کامل یا جزئی برای زمینه خاص آنها مناسب است یا خیر.
فصل 25:لایه ها و مرزها
این فصل به بررسی مفهوم لایه ها و مرزها در سیستم های نرم افزاری می پردازد. آنها از یک بازی کامپیوتری ساده به عنوان مثال استفاده می کنند تا چگونگی تعامل اجزای مختلف مانند رابط کاربری، قوانین تجاری و پایگاه داده با یکدیگر را نشان دهند. نویسنده بر اهمیت مدیریت وابستگی بین این مؤلفه ها به طور مؤثر تأکید می کند و استفاده از API ها را برای جدا کردن آنها پیشنهاد می کند. همچنین ایده مرزهای معماری و چگونگی تعریف آنها را بر اساس محورهای مختلف تغییر، مانند زبان یا مکانیسم ارتباطی، معرفی می کند. این مرزها به جداسازی و سازماندهی بخش‌های مختلف سیستم کمک می‌کنند و درک و نگهداری آن را آسان‌تر می‌کنند.نویسنده نیاز معماران به پیش بینی نیاز به انتزاع و تصمیم گیری آگاهانه در مورد اجرای مرزهای معماری را برجسته می کند. آنها تاکید می کنند که معماران باید هزینه ها و خطرات مربوط به اجرای این مرزها را در نظر بگیرند.
به طور کلی، این فصل بر اهمیت مدیریت صحیح وابستگی‌ها، استفاده از APIها برای جداسازی اجزا، تعریف مرزهای معماری و تصمیم‌گیری آگاهانه در مورد اجرای این مرزها بر اساس هزینه‌ها و ریسک‌ها تاکید می‌کند.
فصل 26 : کامپوننت اصلی
این فصل اهمیت مؤلفه اصلی در یک سیستم و نقش آن در ایجاد، هماهنگی و نظارت بر سایر اجزا را مورد بحث قرار می دهد. مؤلفه اصلی به عنوان نقطه ورود اولیه سیستم عمل می کند و مسئول بارگیری منابع و تنظیمات است. باید از یک چارچوب تزریق وابستگی برای تزریق وابستگی استفاده کند. Main Component به عنوان افزونه ای عمل می کند که شرایط و تنظیمات اولیه برنامه را تنظیم می کند. همچنین اشاره می کند که چندین مؤلفه اصلی را می توان برای پیکربندی ها یا استقرارهای مختلف استفاده کرد.
فصل 27: سرویس ها : بزرگ و کوچک
این فصل محبوبیت معماری های سرویس گرا و میکرو سرویس را مورد بحث قرار می دهد و برخی از مزایای فرضی آنها را به چالش می کشد. این استدلال می کند که سرویس ها به تنهایی یک معماری را تعریف نمی کنند و هنوز هم می توان خدمات را با منابع و داده های مشترک همراه کرد. این فصل مفهوم خدمات مبتنی بر مؤلفه را معرفی می کند که امکان افزودن ویژگی های جدید را بدون تغییر مؤلفه های موجود فراهم می کند. تأکید می کند که معماری یک سیستم با مرزها و وابستگی های آن تعریف می شود، نه فقط مکانیسم های فیزیکی ارتباط و اجرا.
فصل 28 : مرز تست
این فصل بر اهمیت ادغام تست ها در معماری سیستم و طراحی آنها به گونه ای که به خوبی یکپارچه و به طور مستقل قابل استقرار باشند، تاکید می کند. این قانون وابستگی را برجسته می کند، که بیان می کند که تمام تست ها باید به اجزای مورد آزمایش بستگی داشته باشند. این فصل همچنین بر نیاز به آزمایش پذیری برای جلوگیری از شکنندگی و استحکام در آزمایش ها تأکید می کند. پیشنهاد می‌کند از یک API آزمایشی برای جدا کردن تست‌ها از ساختار برنامه استفاده کنید، که امکان تکامل آسان‌تر تست‌ها و کد تولید را فراهم می‌کند. همچنین بر اهمیت جدا نگه داشتن API آزمایشی از سیستم تولید برای اطمینان از امنیت تأکید می کند. این فصل هشدار می‌دهد که نگهداری آزمایش‌هایی که طراحی ضعیفی دارند ممکن است دشوار باشد و ممکن است دور انداخته شوند.
فصل 29 : معماری توکار تمیز
این فصل معماری جاسازی شده پاک توسط جیمز گرنینگ اهمیت مدیریت وابستگی به سیستم عامل و سخت افزار در توسعه نرم افزار تعبیه شده را مورد بحث قرار می دهد. نویسنده بر نیاز به ساختار نرم‌افزار تعبیه‌شده برای عمر طولانی و مفید، به جای صرفاً به کار انداختن آن، تأکید می‌کند. گرنینگ سه فعالیت را در ساختن نرم‌افزار شرح می‌دهد: کارآمد کردن آن، درست کردن آن و سریع‌تر کردن آن. او استدلال می‌کند که به نظر می‌رسد بسیاری از نرم‌افزارهای سیستم‌های جاسازی‌شده‌ای که در طبیعت می‌بیند، با در نظر گرفتن «آن را بساز» نوشته شده‌اند، و تأکید کافی بر ساختار آن برای عمر مفید طولانی‌مدت نشده است. نویسنده همچنین در مورد تعریف سیستم عامل و چگونگی منسوخ شدن آن با تکامل سخت افزار بحث می کند. گرنینگ توضیح می‌دهد که چگونه وابستگی‌های مدیریت نشده می‌توانند نرم‌افزار را از درون نابود کنند و چگونه یک معماری جاسازی شده تمیز برای سلامت بلندمدت محصول مفید است. در نهایت، نویسنده به این نتیجه می‌رسد که افرادی که در حال توسعه نرم‌افزارهای تعبیه‌شده هستند، چیزهای زیادی برای یادگیری از تجربیات خارج از نرم‌افزار تعبیه‌شده دارند.
