بله
آیا درباره اصول و قواعد کاربردی در زمینه طراحی معماری و نرم‌افزارهای آن اطلاعاتی دارید؟ رابرت سی. مارتین در کتاب معماری تمیز همه آنچه که باید درباره این موضوع بدانید را به شما خواهد گفت. این کتاب شامل چند دهه برنامه‌نویسی و چگونگی رفتار در پروژه‌های مختلف برنامه‌نویسی است.
درباره کتاب معماری تمیز
معماری نرم‌افزار یکی از مهارت‌های ضروری و مهم برای همه افرادی است که برنامه‌نویسی حرفه‌ای فعالیت می‌کنند. باید بدانید که اطلاع از قوانین جامع معماری نرم‌افزار و به‌کاربردن این قوانین، به‌شکل قابل توجهی در افزایش بهره‌وری توسعه‌دهنده و طول عمر استفاده از سیستم‌های نرم‌افزاری تاثیرگذار است. رابرت سی. مارتین (Robert C.Martin) در کتاب معماری تمیز (Clean Architecture) قوانین و قواعد مهمی را بیان کرده که با استفاده از آن‌ها می‌توانید عملکرد خود را در پروژه‌های مختلف برنامه‌نویسی بهبود بخشید.
با خواندن این کتاب که در هفت بخش و چهار فصل نوشته شده، موضوعاتی همچون معماری، برنامه‌نویسی ساختار یافته، برنامه‌نویسی شی‌گرا، برنامه‌نویسی تابعی، اصل SPR، اصل OCP، اصل LSP، اصل DIP، قوانین کسب و کار و سویس‌ها را خواهید آموخت.
کتاب معماری تمیز برای چه کسانی مناسب است؟
خواندن این کتاب به کلیه برنامه‌نویسانی که خواهان ورود به دنیای حرفه‌ای برنامه‌نویسی هستند توصیه می‌شود.
با رابرت سی. مارتین بیشتر آشنا شویم
یکی از برنامه‌نویسان معروف دنیا که با نام عمو باب شهرت بیشتری دارد، رابرت سی. مارتین است. او که نزدیک به 5 دهه در زمینه برنامه‌نویسی و کدنویسی فعالیت می‌کند، بنیان‌گذار و رییس شرکت Object Mentor است. او تاکنون توانسته چندین مقاله حرفه‌ای و کاربردی را در مجلات تجاری متنوع منتشر کند و یکی از افراد ثابتی به‌شمار می‌رود که همیشه به عنوان سخنران در کنفرانس‌های بین‌المللی و نمایشگاه‌های تجاری حضور دارد.
در بخشی از کتاب معماری تمیز می‌خوانیم
یک راه برای ساخت یک مرز جزیی این است که تمام کارهای لازم به منظور ایجاد کامپوننت‌های قابل استقرار و کاملا مستقل را انجام دهید و سپس به سادگی آن‌ها را در کنار هم در همان کامپوننت نگه دارید. اینترفیس‌های متقابل وجود دارند، ساختارهای داده ورودی / خروجی وجود دارند و هر چیزی که به طور کامل راه‌اندازی شده، اما ما تمام آن‌ها را به عنوان یک کامپوننت واحد کامپایل کرده و توسعه می‌دهیم.
بدیهی است که این نوع مرز جزیی به همان مقدار کد نیاز دارد و طراحی مقدماتی به عنوان یک مرز کامل کار می‌کند. با این حال، نیازی به اجرای چندین کامپوننت نیست. هیچ شماره ویرایشی برای ردیابی یا شماره انتشاری وجود ندارد. این اختلاف نباید بدون دلیل پذیرفته شود. این استراتژی اولیه پشت FitNesseبود. کامپوننت وب سرور FitNesseطوری طراحی شده بود که قابلیت جدا شدن از Wiki و بخش تست FitNesse را داشته باشد. ایده این بود که ممکن است بخواهیم برنامه‌های کاربردی مبتنی بر وب دیگری را با استفاده از کامپوننت وب ایجاد کنیم. در عین حال، نمی‌خواستیم کاربران مجبور باشند دو کامپوننت را دانلود کنند. به یاد بیاورید که یکی از اهداف طراحی‌های ما "دانلود کردن و استفاده کردن" بود. هدف ما این بود که کاربران، یک فایل jar را دانلود کنند و آن را بدون نیاز به جست‌وجوی فایل‌های jar دیگری و تعبیه قابلیت‌های سازگاری نسخه و غیره اجرا کنند.
