خلاصه فصل 15 تا 34 کتاب معماری تمیز

خلاصه فصل‌های 15 تا 29:این خلاصه بر اصول و شیوه‌های ساخت سیستم‌های نرم‌افزاری با معماری که حول عملکردهای اصلی سیستم متمرکز است، قابلیت نگهداری، انعطاف‌پذیری و استقلال از چارچوب‌ها را ارتقا می‌دهد و از قابلیت آزمایش پشتیبانی می‌کند، تأکید دارد. این خلاصه به ایده های کلیدی ارائه شده در این کار می پردازد و اهمیت ایجاد معماری نرم افزاری را که موارد استفاده اساسی سیستم را اولویت بندی می کند، برجسته می کند.اصل اساسی معماری تمیز این است که معماری سیستم باید در درجه اول با موارد استفاده آن تعریف شود. موارد استفاده نشان دهنده عملکردهای اساسی و قوانین تجاری سیستم است.معماری باید به گونه ای سازماندهی و ساختار یافته باشد که به طور مستقیم موارد استفاده سطح بالایی را که سیستم قرار است به آن خدمت کند، منعکس کند.با ساختاردهی معماری حول موارد استفاده، برقراری ارتباط با هدف و طراحی سیستم با ذینفعان، اعضای تیم و توسعه دهندگان آینده آسان تر می شود. رویکرد مورد استفاده معماران را قادر می‌سازد تا تصمیمات طراحی را اتخاذ کنند که مستقیماً با عملکرد اصلی مرتبط هستند، بدون اینکه درگیر جزئیات فنی یا نگرانی‌های زیرساختی شوند.جداسازی از چارچوب ها: یکی از نکات کلیدی این خلاصه، نیاز به مستقل نگه داشتن معماری نرم افزار از چارچوب ها، کتابخانه ها، پایگاه های داده و سایر ابزارهای خاص است. این امر بسیار مهم است زیرا انجام تعهدات اولیه نسبت به این فناوری‌ها می‌تواند انعطاف‌پذیری و سازگاری سیستم را با تکامل پروژه مختل کند.هدف معماران باید ایجاد طرحی باشد که امکان تصمیم گیری های معوق در مورد چارچوب ها یا ابزارهایی را که باید استفاده کنند را فراهم کند. این انعطاف‌پذیری به این معناست که نرم‌افزار را می‌توان به راحتی و بدون تعمیرات اساسی معماری تغییر داد. به عنوان مثال، تصمیم گیری در مورد چارچوب های وب، پایگاه های داده یا حتی پلت فرم های استقرار باید از معماری اصلی جدا باشد. این جداسازی تضمین می‌کند که معماری به‌جای ویژگی‌های استک فناوری، بر روی موارد استفاده و منطق تجاری متمرکز می‌ماند.چارچوب ها ابزار هستند، نه پایه: در حالی که چارچوب ها می توانند فوق العاده مفید باشند، نباید معماری کلی سیستم نرم افزار را دیکته کنند. چارچوب ها ابزارها و ابزارهایی را برای وظایف خاص ارائه می دهند، اما نباید نیروی هدایت کننده در پشت تصمیمات معماری باشند. معماران باید به طور انتقادی ارزیابی کنند که چگونه از این چارچوب ها برای تامین نیازهای سیستم استفاده کنند بدون اینکه اجازه دهند آنها بر ساختار سیستم تسلط یا دیکته کنند.حفظ تاکید قوی مورد استفاده در معماری بسیار مهم است. این بدان معنی است که منطق و عملکرد اصلی تجارت باید در وحله اول باشد، در حالی که چارچوب ها و وابستگی های خارجی برای پشتیبانی از این موارد استفاده اصلی یکپارچه شده اند. معماری همچنان بر نحوه عملکرد سیستم کنترل دارد و چارچوب ها به ابزارهایی تبدیل می شوند که اجرای آن را تسهیل می کنند.معماری‌های قابل تست: یک معماری با طراحی خوب، متمرکز بر موارد استفاده و جدا از چارچوب‌ها، به شدت در معرض یونیت تست است. یونیت تست یک عمل مهم در توسعه نرم افزار است، زیرا به شناسایی و رفع مشکلات در مراحل اولیه توسعه کمک می کند. یک معماری تمیز باید امکان تست واحد را بدون نیاز به وابستگی های خارجی پیچیده، مانند سرورهای وب یا پایگاه داده، فراهم کند.این تست پذیری تضمین می‌کند که عملکردهای اصلی سیستم را می‌توان به صورت مجزا تست کرد و باعث افزایش پایداری و قابلیت اطمینان می‌شود. این به توسعه دهندگان اجازه می دهد تا بررسی کنند که موارد استفاده، که ارزش اصلی سیستم را تعیین می کنند، به درستی کار می کنند.قابلیت نگهداری و شفافیت: این خلاصه بر اهمیت ایجاد معماری که به وضوح هدف سیستم نرم افزار را بیان می کند، تاکید می کند. هنگامی که توسعه دهندگان جدید سورس کد را بررسی می کنند، باید بتوانند به سرعت ماهیت برنامه را درک کنند.اصول معماری تمیز از معماری هایی حمایت می کند که عملکرد اصلی، انعطاف پذیری و قابلیت نگهداری را بر فناوری های خاص اولویت می دهند. این رویکرد منجر به سیستم‌های نرم‌افزاری تمیزتر، سازگارتر و قابل آزمایش‌تر می‌شود که بر موارد استفاده اولیه خود متمرکز هستند.این بخش از خلاصه که اسمش را میگذاریم "معماری تمیز - لایه ها و مرزها" کاوش عمیقی از مفهوم حیاتی مرزهای معماری در طراحی نرم افزار است. چگونگی فراگیر شدن این مرزها در سیستم‌های نرم‌افزاری را روشن می‌کند و مسئولیت معمار را برای شناسایی زمان و مکان لازم برای ساختن یک سیستم برجسته می‌کند. این خلاصه از یک مثال ساده و در عین حال مؤثر استفاده می‌کند، یک بازی مبتنی بر متن به نام Hunt the Wumpus تا بینش‌های عملی در مورد اینکه چگونه مرزهای معماری می‌توانند در زمینه‌های مختلف پدیدار شوند و در نهایت اثربخشی و انعطاف‌پذیری نرم‌افزار را شکل دهند، ارائه می‌کند.در هسته خود، این خلاصه بیان می کند که مرزهای معماری در سیستم های نرم افزاری، صرف نظر از پیچیدگی آنها، همه جا حضور دارند. مثال Hunt the Wumpus، یک بازی ماجراجویی است که مفهوم مرزهای معماری را معرفی می کند. این بازی از دستورات مستقیمی مانند GO EASTو SHOT WESTاستفاده می کند، اما این سادگی به طور موثری پتانسیل مرزهای معماری را نشان می دهد. در این زمینه، بازی از اجزای متعددی از جمله رابط کاربری ، قوانین بازی و ذخیره سازی داده ها تشکیل شده است. این کامپوننت ها به روش‌های مختلفی با هم تعامل دارند و بدون مرزهای مناسب، سیستم می‌تواند در هم پیچیده شود و مدیریت و گسترش آن را چالش برانگیز کند. این خلاصه تاکید می کند که این مفهوم برای سیستم های نرم افزاری پیچیده تر صادق است و اهمیت تشخیص نیاز به مرزهای معماری را برجسته می کند.این خلاصه این ایده حیاتی را معرفی می کند که معماران باید الزامات آینده را پیش بینی کنند و تصمیمات آگاهانه ای در مورد اجرای مرزهای معماری بگیرند. هدف این است که این مرزها را در مقطعی بهینه معرفی کنیم، زمانی که هزینه های اجرای آنها با مزایایی که ارائه می کنند توجیه شود.بحث اصلی حول نقش حیاتی معماران در تشخیص نیاز به مرزهای معماری و تصمیم گیری آگاهانه در مورد اجرای آنها می چرخد.در اصل، این خلاصه تأکید می کند که مرزهای معماری نه تنها مرتبط هستند، بلکه در طراحی نرم افزار ضروری هستند. این یک چشم انداز فکری در مورد فرآیند طراحی معماری ارائه می دهد و اهمیت پیش بینی هوشمند و تصمیم گیری فعال را برجسته می کند. این ادعا می کند که معماران باید در طول چرخه عمر توسعه نرم افزار هوشیار باقی بمانند و به طور مداوم ارزیابی کنند که چه زمانی و در کجا مرزهای معماری ضروری است. هدف کلی این است که این مرزها را دقیقاً در لحظه مناسب پیاده سازی کنیم، تعادلی بین مهندسی بیش از حد و مهندسی کم ایجاد کنیم و موفقیت بلندمدت سیستم نرم افزار را تضمین کنیم.Clean Embedded Architecture:این بخش از خلاصه با پرداختن به یک مسئله رایج در زمینه توسعه نرم‌افزار تعبیه‌شده آغاز می‌شود. نویسنده به درستی اصول توسعه نرم‌افزار Kent Beck را به کار می‌برد که شامل رویکردی پیشرونده می‌شود: «عملکرد آن»، «درست کردن آن» و در نهایت «سریع کردن آن». با این حال، اشاره شده است که بسیاری از سیستم‌های تعبیه‌شده ظاهراً در مرحله «کارکرد آن» به دام افتاده‌اند و صرفاً بر روی عملکرد تمرکز می‌کنند.این خلاصه مفهوم "App-titude test" را معرفی می کند. بر اهمیت ایجاد کد تمیز و قابل نگهداری تأکید دارد. چند قطعه کد ارائه شده است تا نشان دهد که چگونه توابع باید بر اساس concern های خاص خود دسته بندی شوند.جدا کردن کد از سخت افزار و ابزار:این بخش به موضوع درهم تنیده شدن کد با سخت افزار و مجموعه ابزارهای خاص در سیستم های تعبیه شده می پردازد که منجر به چالش هایی مانند کاهش قابلیت حمل و نگهداری می شود. این خلاصه بیان می‌کند که انتخاب پردازنده در یک برنامه تعبیه‌شده یک جنبه حیاتی است.این خلاصه بر نیاز به اجتناب از کدهایی که به شدت به یک پردازنده یا زنجیره ابزار خاص گره خورده است تأکید می کند. از معرفی یک لایه انتزاعی سخت افزاری (HAL) دفاع می کند که به عنوان یک واسطه عمل می کند و کد را از پیچیدگی های سخت افزاری دور می کند. با استفاده از HAL، توسعه‌دهندگان می‌توانند کد خود را portable تر و قابل انتقال‌تر بین پلتفرم‌های سخت‌افزاری مختلف یا زنجیره‌های ابزار توسعه دهند.Substitutability and Conditional Compilation:کامپایل شرطی، که معمولاً برای فعال یا غیرفعال کردن بخش‌های کد بر اساس هدف یا سیستم عامل استفاده می‌شود، می‌تواند منجر به تکرار بیش از حد کد شود که اصل «تکرار نکنید» (DRY) را نقض می‌کند.کامپایل شرطی به ویژه در سیستم های embedded هنگام شناسایی نوع سخت افزار هدف رایج است. این ایده یک لایه انتزاعی سخت افزاری (HAL) را معرفی می کند تا جزئیات خاص سخت افزار را مبهم کند، بنابراین نیاز به کامپایل شرطی را کاهش می دهد. به جای تکیه بر کامپایل مشروط، استفاده از linkers or runtime binding mechanisms برای ایجاد ارتباط بین اجزای نرم‌افزار و سخت‌افزار خوب است.خلاصه فصل‌های 30 تا 34:این بخش با نقد معماری لایه‌ای مرسوم آغاز می‌شود و تاکید می‌کند برای تسهیل وابستگی‌ها به اینترفیس های عمومی متکی باید بود. ادعا می کند که public کردن همه typeها، اهمیت تمایزات معماری را نفی می کند.این مقاله چهار رویکرد معماری مختلف را معرفی می‌کند .“package by layer," "package by feature" "ports and adapters" and "package by component"هر رویکرد ابزار متمایز سازماندهی کد برای پشتیبانی از اهداف معماری را ارائه می دهد.در "package by layer"، کد بر اساس عملکردهای فنی به لایه های افقی تقسیم می شود. با این حال، این رویکرد مستلزم پابلیک بودن برخی از اینترفیس ها است که کپسوله‌سازی را تضعیف می‌کند.رویکرد "package by feature" شامل سازماندهی کد حول ویژگی های خاص است.در حالی که می تواند دسترسی به اجزای داخلی را کاهش دهد، ممکن است استفاده مجدد از کامپوننت ها توسط سایر بخش های برنامه را محدود کند.معماری ""ports and adaptersبه دنبال جدا کردن منطق تجاری از جزئیات پیاده سازی فنی است. برای اجرای این جدایی ، از دامین و زیرساخت استفاده می کنیم. اینترفیس ها انتخابی باید پابلیک باشند و از اجرای قوانین معماری اطمینان حاصل شود.رویکرد ""package by component فانکشنالیتی های مرتبط را با هم ترکیب می کند. این رویکرد رابط کاربری را جدا از اجزا و با حداقل اینترفیس های پابلیک نگه می دارد.این مقاله به تفکیک کد به درختان کد مختلف برای اعمال اصول معماری به طور موثر اشاره می کند، اما پیچیدگی ها و چالش های بالقوه نگهداری در این رویکرد را تصدیق می کند. یک جایگزین ارائه شده است، با دو درخت کد اولیه برای دامین و زیرساخت.این خلاصه با تأکید بر اهمیت نگاشت دقیق طرح‌های معماری مورد نظر در ساختارهای کد به پایان می‌رسد. از در نظر گرفتن نحوه سازماندهی کد، استفاده از حالت‌های دی کاپلینگ و اهمیت access modifiers برای اطمینان از کپسوله‌سازی حمایت می‌کند. پیام این است که عملگرا باشید و اندازه و سطح مهارت تیم توسعه، پیچیدگی پروژه و محدودیت های بودجه را در نظر بگیرید. در نهایت، بر اهمیت استفاده از کامپایلر برای کمک به اجرای سبک معماری انتخابی و اجتناب از unwanted coupling ، مانند مدل‌های داده، تأکید می‌کند.سینا علیزاده