مسعود بهرامی
معرفی کتاب Clean Architecture: A Craftsman’s Guide to Software Structure and Design
- نویسنده: رابرت سی. مارتین (معروف به Uncle Bob)
- سال انتشار: ۲۰۱۷
- تعداد صفحات: ۴۳۲ صفحه
- ژانر: معماری نرمافزار، طراحی سیستم، اصول مهندسی
- سطح مطالعه: متوسط (حداقل ۲ سال تجربه عملی توصیه میشود)
Uncle Bob کیست و چرا حرفش مهم است؟
رابرت مارتین، معروف به «Uncle Bob»، یکی از تأثیرگذارترین چهرههای صنعت نرمافزار در چند دهه اخیر است. او یکی از نویسندگان اصلی مانیفست توسعه چابک (Agile Manifesto)، نویسنده کتاب پرفروش Clean Code، و یکی از بزرگترین مدافعان اصول مهندسی نرمافزار تمیز و حرفهای است.
اگر کتاب Clean Code درباره تمیزی در سطح کد بود (چطور یک تابع بنویسی، چطور یک کلاس نامگذاری کنی)، کتاب Clean Architecture درباره «میزی در سطح معماری است! این کتاب به تو یاد میدهد چطور سیستم را طوری لایهبندی کنی که:
- وابستگیها فقط یک جهت داشته باشند (به سمت داخل)
- جزئیات (مثل دیتابیس، فریمورک، UI) از منطق اصلی کسبوکار جدا باشند
- بتوانی دیتابیس یا فریمورک را بدون تغییر در منطق اصلی عوض کنی
مشکل اصلی – معماری یعنی چه؟
یک سؤال ساده اما عمیق: «عماری نرمافزار یعنی چه؟
خیلی از توسعهدهندگان فکر میکنند معماری یعنی دیاگرام کشیدن یا انتخاب فریمورک یا«تصمیم گرفتن از کدام دیتابیس استفاده کنیم. Uncle Bob در این کتاب، تعریف متفاوتی ارائه میدهد:
معماری، آن چیزهایی است که میخواهی دیرتر تصمیم بگیری.
یعنی معماری خوب، سیستمی میسازد که تصمیمهای مهم (مثل انتخاب دیتابیس یا فریمورک) را تا آخرین لحظه ممکن به تأخیر میاندازد. چون این تصمیمها هزینه بالایی دارند و اگر زود گرفته شوند، ممکن است اشتباه از آب دربیایند.
معماری خوب، سیستمی میسازد که:
بدون تغییر در منطق اصلی، بتوانی دیتابیس را از MySQL به PostgreSQL عوض کنی
بدون تغییر در منطق اصلی، بتوانی UI را از وب به موبایل تغییر دهی
بدون تغییر در منطق اصلی، بتوانی فریمورک وب را از Spring به Django مهاجرت کنی
این به نظر آرمانگرایانه میآید، اما Uncle Bob نشان میدهد که با رعایت چند اصل ساده، شدنی است.
هسته کتاب؛ معماری تمیز و لایهبندی
کل کتاب حول یک نمودار ساده اما قدرتمند میچرخد: لایههای معماری تمیز (The Clean Architecture).
قاعده طلایی:
وابستگیها فقط از بیرون به داخل هستند. لایههای داخلی چیزی درباره لایههای بیرونی نمیدانند. لایه Entities از Use Cases خبر ندارد، Use Cases از Interface Adapters خبر ندارد، و Interface Adapters از Frameworks خبر ندارد.
لایه اول: Entities (هسته)
این لایه، قلب سیستم است. شامل قوانین بیزنس سازمانی – یعنی قوانینی که در کل سازمان معنا دارند، مستقل از اپلیکیشن خاص. مثلاً در یک سیستم بانکی، «نحوه محاسبه سود وام» یک Entity است. حتی اگر اپلیکیشن را عوض کنی، این قانون باید حفظ شود.
نکته: Entities نه تنها به دیتابیس وابسته نیست، بلکه حتی نمیداند دیتابیس وجود دارد. Entities فقط منطق خالص بیزنس است.
لایه دوم: Use Cases
این لایه، قوانین بیزنس مختص اپلیکیشن را پیاده میکند. Use Cases جزییات تعامل کاربر با سیستم را مدیریت میکند. مثلاً «ثبتنام کاربر جدید» یک Use Case است. این Use Case میداند که باید Entities را صدا بزند، اما نمیداند داده از کجا میآید یا کجا ذخیره میشود.
لایه سوم: Interface Adapters
این لایه، داده را بین Use Cases و دنیای بیرون (دیتابیس، UI، API) تبدیل میکند. شامل:
Controllerها (دریافت درخواست از کاربر و تبدیل به فرمت مناسب برای Use Case)
Presenterها (دریافت خروجی Use Case و تبدیل به فرمت مناسب برای UI)
Gateways (اینترفیسهایی که Use Cases از طریق آنها با دیتابیس حرف میزنند)
Frameworks & Drivers
این لایه، جایی است که جزییات واقعی قرار میگیرد: دیتابیس (MySQL, PostgreSQL, MongoDB)، فریمورک وب (Spring, Django, Express)، کتابخانههای خارجی، و هر چیز دیگری که به یک ابزار خاص وابسته است.
قاعده طلایی: این لایه باید کمترین کد را داشته باشد. هر جا توانستی منطق را به لایههای بالاتر ببری، ببر.
اصول کلیدی معماری تمیز
Uncle Bob در این کتاب، پنج اصل را معرفی میکند که پایههای معماری تمیز هستند. این اصول در واقع نسخه گسترشیافته همان اصول SOLID هستند که در سطح معماری اعمال میشوند.
۱. اصل تغییر جهت وابستگیها(Dependency Inversion)
این اصل میگوید:
ماژولهای سطح بالا (Use Cases, Entities) نباید به ماژولهای سطح پایین (دیتابیس، فریمورک) وابسته باشند. هر دو باید به انتزاع (Interface) وابسته باشند.
یعنی در کد، به جای اینکه مستقیماً تابعهای دیتابیس را صدا بزنی، یک اینترفیس (مثل UserRepository) تعریف میکنی و لایه دیتابیس آن را پیادهسازی میکند. Use Case فقط این اینترفیس را میشناسد، نه پیادهسازی واقعی.
۲. اصل مرزها (Boundaries)
Uncle Bob اصرار دارد که مرزهای معماری باید به وضوح مشخص شوند. هر لایه باید یک مرز ترسیم شده داشته باشد و هیچ چیز از لایه بیرونی نباید به لایه داخلی نفوذ کند.
این یعنی: در کد Entities، نباید حتی یک import از لایه Use Cases یا Interface Adapters وجود داشته باشد. در کد Use Cases، نباید از لایه Frameworks چیزی import شود.
۳. معماری پلاگینپذیر (Plugin Architecture)
اگر اصول بالا رعایت شود، سیستم شما تبدیل به یک معماری پلاگینپذیر میشود. این بدین معنی است که شما میتوانید، دیتابیس را عوض کنی (کافی است یک پلاگین جدید بنویسی که اینترفیسها را پیادهسازی کند)، میتوانی UI را عوض کنی (از وب به موبایل، بدون تغییر در Use Cases) و همینطور میتوانی فریمورک را عوض کنی (از Spring به Quarkus، بدون تغییر در منطق)
۴. قاعده اسبابی (The Screaming Architecture)
Uncle Bob میگوید:
معماری یک نرمافزار باید فریاد بزند و بگوید که این سیستم چه کاری انجام میدهد، نه اینکه از چه ابزاری استفاده میکند.
۵. تستپذیری (Testability)
اگر معماری تمیز باشد، تست کردن Use Cases باید بسیار ساده باشد. چون Use Cases به هیچ زیرساخت واقعی وابسته نیست (به اینترفیس وابسته است)، میتوانی در تست، یک پیادهسازی دامی (Mock) از Repositoryها و Gatewayها ارائه دهی و Use Case را ایزوله تست کنی.
نقل قولهای کلیدی از کتاب
معماری خوب، سیستم را قابل فهم، قابل تغییر، و قابل نگهداری میکند. معماری بد، سیستم را به یک بمب ساعتی تبدیل میکند.
نرمافزار یعنی تغییر. معماری خوب، تغییر را آسان میکند. معماری بد، تغییر را سخت و پرهزینه.
وقتی میبینی یک تصمیم معماری باعث میشود نتوانی دیتابیس را عوض کنی، یعنی اشتباه کردهای. دیتابیس یک جزییات است. جزییات باید دیرتر تصمیم گرفته شوند.
تستپذیری، نشانه معماری خوب است. اگر سیستم تستپذیر نیست، معماریات مشکل دارد.
سخن پایانی
کتاب Clean Architecture، فقط راهنمای لایهبندی نیست. یک بیانیه فلسفی درباره اینکه نرمافزار خوب یعنی چه. Uncle Bob به تو یاد میدهد که معماری را جدی بگیری، نه به عنوان یک کار تشریفاتی، بلکه به عنوان تنها راه نجات یک سیستم از مرگ تدریجی.
