آشنایی با Clean Architecture (آموزش معماری تمیز) - مقدمات (قسمت اول)

قسمت اول : مقدمات (شما در حال خواندن این مقاله هستید)
قسمت دوم : مبانی معماری
قسمت سوم : نگاهی به معماری سنتی سه لایه
قسمت چهارم : اجزای Clean Architecture
قسمت پنجم : پیاده سازی بر اساس سرویس ها
قسمت ششم : پیاده سازی بر اساس UseCase ها
قسمت هفتم (قسمت آخر) : آشنایی با CQRS

این مجموعه به جز هفت قسمت فوق، به شکل یک دوره آموزشی ویدیویی نیز تهیه شده است و از طریق لینک زیر قابل دسترسی است:
دوره آموزشی Clean Architecture

در مقالات آموزش معماری تمیز یا همون Clean Architectureمی‌خوام به شکلی ساده و کاملا عملی در مورد CA مطالبی رو با شما به اشتراک بگذارم. به نظرم عبارت «مهماری تمیز» ترجمه ای بد برای Clean Architecture هست اما به دلیل سرچ شدن در گوگل و تکرار در مقالات، مجبورم از این عبارت هم در نوشته ها استفاده کنم.

همین الان به فارسی عبارت «آشنایی با Clean Architecture» یا «آموزش Clean Architecture» رو سرچ کنید. نتایج فارسی واقعا کم هست. چند دقیقه وقت بذارید و بخونیدشون.

چیزی دستگیرتون شد؟
بنظرم مشکل مقالات توی این زمینه و زمینه های مشابه رو میشه به دو دسته تقسیم کرد:

• دسته اول : نویسنده مقاله با ترجمه ای بد با معادلسازی های بدتر از منابع خارجی قرار هست چیزی به ما آموزش بده که خودش ازش سر در نیاورده.
• دسته دوم : نویسنده مقاله مسلط به این معماری هست ولی متاسفانه خیلی با کسی که هنوز هیچ چیز نمیدونه فاصله داره و فراموش کرده که از جایی شروع کنه که باید شروع کنه!

این مجموعه نوشته قرار هست شبیه دسته اول نباشه. اگر بخشی از نوشته ترجمه هست چند بار بازنویسی شده تا برای همه قابل فهم باشه، ضمن اینکه این نوشته قرار هست مقدمه ای برای دسته دوم هم باشه. یعنی اول مطالب ساده رو بخونید و متوجه بشید و بعد سراغ مقالات دسته دوم برید.

این مجموعه کاملا مقدماتیست و برای افرادی پیشنهاد می‌شود که برنامه نویسی را بلد هستند.

قسمت ششم پادکست کافه برنامه نویس هم در مورد همین موضوع هست و به محض منتشر شدن لینکش در این پست قرار داده میشه.

بطور کلی معماری نرم افزار شامل تعاریفی مربوط به ساختار نرم افزار است.

اینکه چه کارهایی برای بهینه شدن یا agile شدن سیستم باید انجام داد در چارچوب همین معماری قابل دستیابی است.

با یک مثال شروع میکنم که همین ابتدا به لحاظ ذهنی با هم هماهنگ شویم.

دو شرکت نرم افزاری را تصور کنید. که هر دو دارای تعداد کارمند یکسان و با مهارت های یکسان هستند.

اولین شرکت به روش A کار میکند و پروژه ها را به افراد حرفه ای خود میسپارد. معمولا پروژه هایش به شکلی است که هر فرد میتواند روی یک پروژه متمرکز شود. هر فرد به دلخواه کد می‌نویسد و معماری مورد نظر خود را پیاده میکند. گاها مدیر شرکت تصمیم میگیرد که پروژه‌ی بزرگتر را به دو نفر بسپارد؛ آن دو هم بین خودشان تقسیم وظایف میکنند و کار را با موفقیت به پایان میرسانند.

دومین شرکت به روش B کار میکند و افراد شرکت با تمام حرفه‌ای بودن هر کدام روی یک بخش از کار متمرکز هستند. همه در انجام همه پروژه‌ها سهیم هستند اما هر کس روی بخش خاصی کار میکند. پروژه‌ها روی یک چارچوب خاص از قبل پیاده شده سوار میشوند که همه برنامه نویسان آن شرکت نسبت به آن چارچوب تسلط دارند.

اینکه خروجی نهایی شرکت A بهتر است یا B بحث معماری نرم افزار نیست.

اینکه در حالت A افراد شرکت شاید بازه‌ی وسیعی از مهارت ها را پیدا کنند هم شکی در آن نیست. چون در حالت B فرد متمرکز روی پیاده سازی های منحصر به خود است و اگر خودش نخواهد شاید همیشه همانجایی که هست باقی بماند (به لحاظ دانش).

بطور کلی حالت A مزیت هایی دارد که برای پروژه های نسبتا کوچک مناسب‌تر است.

اینکه تمرکز روی یک پروژه وجود دارد و فرد پاسخگوی خروجی خود است مزیت محسوب میشود اما اگر در حالت B بتوانیم این دو خصوصیت را اعمال کنیم ،در کل حالت B مزیت های بیشتری دارد.

میتوان ساختار نرم افزار را طوری تنظیم کرد که هر فرد پاسخگوی بخشی که توسعه میدهد باشد بدون آنکه از بقیه بخش ها باخبر باشد. هر فرد فقط متمرکز روی بخش همیشگی خود باشد و به لحاظ کد نویسی از چارچوب خاصی خارج نشود.

مزیت های روش B :

• اگر دی کوپل شدن اعضای سیستم فکر شده باشد، ضمن اینکه میتوان هر بخش را به فردی محول کرد این فرد هنگام توسعه کمترین وابستگی را به دیگر بخش‌ها خواهد داشت و کمتر منتظر نتیجه کار بقیه می‌ماند!
• دی کوپل بودن و کاهش وابستگی‌ها باعث می‌شود تست کردن هر بخش ساده‌تر و سریع‌تر باشد
• جداشدن یک فرد از شرکت‌ باعث لطمه به ساختار نخواهد شد. فرد جدید میتواند سریعا بخش مربوط به آن فرد را آموزش دیده و در همان حوزه متخصص شود. (در صورتی که در حالت شرکت A این اتفاق لطمات جبران ناپذیری به شرکت وارد میکند)
• نگهداری و بهینه سازی و عیب یابی ساده‌تر خواهد بود، چون سیستم به لحاظ ساختاری قابلیت سریع تعویض بخش هایی از کد و جاگذاری یک کامپوننت با کامپوننت دیگر را دارد.
• در این حالت شاید ساختار نرم افزار در کل پیچیده باشد اما این پیچیدگی ها اتفاقی نیست و پشت هر کدام فلسفه ای وجود دارد؛ به علاوه اینکه دی کوپل کردن وظایف بین افراد باعث میشود همه درگیر پیچیدگی سیستم نباشند و هر کس در بخش خودش تخصص کسب کند.

اما در مورد خود نرم افزار چه میتوان گفت؟

معمولا در مثال ها برای مقایسه ساختار بد و خوب از ماکارونی و لازانیا استفاده میشود.(منبع)

ماکارونی را میتوان به عنوان messy code و لازانیا را به عنوان clean code در نظر گرفت.
هر دو خوشمزه هستند و هر دو تزئین شدنی اند! همانطور که خروجی شرکت A و B میتواند هر دو خوب و عالی باشد.

اما ماکارونی ساختار بدی دارد چون جدا کردن رشته ها از همدیگر سخت است.
به هر رشته دست بزنید بقیه رشته ها هم تحت تاثیر قرار میگیرند.
سر و ته یک رشته به سختی قابل تشخیص است.
اصلا میتوانید یک رشته را بردارید و رشته دیگری جایگزین آن کنید!؟

اما لازانیا لایه لایه است.
میتوانید یک لایه را جدا کنید.
میتوانید کل لازنیا را به چند بخش تقسیم کنید.
به راحتی گوشت و ورق های نودل قابل تشخیص و جدا شدن هستند.

در مورد messy code میشه موارد زیر را گفت:

• به یک معماری پیچیده زمانی که پیچیدگی نیاز نیست هم messy میگویند.
• ناهماهنگی در اجزای نرم افزار که به طور مناسب در کنار هم چیده نشده باشند و به تعبیری قواعد solid در آن رعایت نشده باشد مثل کلاس ها و متدهای نامرتبط که باز messy است.
• سخت بودن تغییر و توسعه به شکلی که در طول زمان به روز رسانی کدها یا جایگزینی آنها سخت باشد و منجر به تغییرات زیاد در بخش های دیگر باشد و یا باعث بوجود آمدن خطاهای پیش بینی نشده شود هم messy است.
• امکان تست برای بخش های مختلف نرم افزار به شکل مستقل وجود نداشته باشد هم messy میگویند.

اما clean code چه نوع کدی است؟

• کدها ساده هستند و پیچیدگی تنها زمانی وجود دارد که راه ساده تری وجود نداشته باشد.
• کدها قابل فهم هستند و قرار گیری هر جز در هر جایی دلیل و منطق خود را در کل معماری نرم افزار دارد و قواعد solid رعایت شده
• انعطاف پذیر است و میتوان به راحتی چیزی به آن اضافه کرد یا بخشی از آن را حذف کرد.
• وجود بخش ها مختلف ضرورت دارد.
• تست پذیری به شکل جزئی و کلی ساده است.
• نگهداری و توسعه کدها ساده است.

قرار هست روش هایی پیدا کنیم که این clean code به شکل ساختاری باعث تعادل هزینه سیستم و بهینه شدن روند توسعه شود.

در بخش بعدی در مورد معماری سه لایه و ارتباط آن با clean code خواهم نوشت. اگر حس می کنید بخشی از مطلب نامفهوم است نظر خود را بنویسید تا توضیح بیشتری ارائه کنم؛ قرار نیست فقط بخاطر پر کردن صفحه، مطلبی نوشته شده باشد.