معماری Clean Architecture در اندروید

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

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

Clean Architecture که توسط Robert C. Martin معرفی شد، مجموعه‌ای از اصول و الگوهای طراحی را ارائه می‌دهد که هدف آن جداسازی مسئولیت‌ها، کاهش وابستگی بین لایه‌ها، افزایش تست‌پذیری و بهبود نگهداری پروژه در بلندمدت است. این معماری به توسعه‌دهندگان کمک می‌کند منطق کسب‌وکار (Business Logic) را از جزئیات پیاده‌سازی مانند رابط کاربری، دیتابیس و سرویس‌های شبکه مستقل نگه دارند.

دیاگرام معماری Clean Architecture در اندروید

در توسعه مدرن اندروید، استفاده از ابزارهایی مانند Jetpack Compose، ViewModel، Coroutines، Flow، Hilt و Retrofit در کنار Clean Architecture می‌تواند ساختاری قدرتمند، مقیاس‌پذیر و استاندارد برای پروژه‌های کوچک و بزرگ ایجاد کند. به همین دلیل بسیاری از شرکت‌های نرم‌افزاری و تیم‌های حرفه‌ای توسعه اندروید، Clean Architecture را به عنوان یکی از معماری‌های اصلی پروژه‌های خود انتخاب می‌کنند.

در این مقاله با مفاهیم اصلی Clean Architecture، لایه‌های مختلف آن، نحوه ارتباط بین لایه‌ها، مزایا و معایب این معماری و همچنین پیاده‌سازی آن در پروژه‌های اندرویدی آشنا خواهیم شد.

معماری‌های برنامه‌نویسی در اندروید

در طول سال‌های گذشته، معماری‌های مختلفی برای برنامه نویسی اندروید معرفی شده‌اند که از مهم‌ترین آن‌ها می‌توان به MVC (Model-View-Controller)، MVP (Model-View-Presenter) و MVVM (Model-View-ViewModel) اشاره کرد. هر یک از این معماری‌ها با هدف سازمان‌دهی بهتر کدها، تفکیک مسئولیت‌ها و افزایش قابلیت نگهداری پروژه به وجود آمده‌اند و تا حد زیادی توانسته‌اند مشکلات توسعه نرم‌افزار را کاهش دهند.

با این حال، زمانی که یک پروژه اندرویدی رشد می‌کند و تعداد قابلیت‌ها، ماژول‌ها و اعضای تیم افزایش می‌یابد، محدودیت‌های این معماری‌ها بیشتر نمایان می‌شود. در بسیاری از پروژه‌ها، منطق کسب‌وکار به تدریج در ViewModel، Presenter یا Controller پراکنده می‌شود و وابستگی میان لایه‌های مختلف افزایش پیدا می‌کند. نتیجه این وضعیت، تولید کدهایی است که نگهداری، توسعه و تست آن‌ها به مرور زمان دشوارتر می‌شود.

برای مثال، در معماری MVVM که امروزه یکی از محبوب‌ترین معماری‌های اندروید محسوب می‌شود، معمولاً ViewModel به مرور زمان مسئولیت‌های متعددی را بر عهده می‌گیرد. این موضوع باعث ایجاد کلاس‌های بزرگ و پیچیده (God Classes) می‌شود که تست و توسعه آن‌ها هزینه زیادی دارد.

هدف از معماری Clean Architecture در اندروید

معماری Clean Architecture که توسط Robert C. Martin معرفی شده است، با هدف جداسازی کامل لایه‌های مختلف برنامه و کاهش وابستگی بین آن‌ها ارائه شده است. این معماری باعث می‌شود که:

• کد خواناتر و قابل نگهداری‌تر شود.
• تست‌پذیری برنامه افزایش یابد.
• وابستگی به فریمورک‌های خارجی کاهش یابد.
• توسعه‌دهندگان بتوانند به راحتی بخش‌های مختلف برنامه را تغییر دهند.

Clean Architecture برای حل همین چالش‌ها طراحی شده است. این معماری با جداسازی کامل منطق کسب‌وکار از لایه‌های رابط کاربری، شبکه و پایگاه داده، ساختاری ارائه می‌دهد که در آن هر بخش تنها مسئول انجام وظایف مشخصی است. در نتیجه، وابستگی بین لایه‌ها به حداقل می‌رسد و تغییر در یک بخش از سیستم تأثیر مستقیمی بر سایر بخش‌ها نخواهد داشت.

مهم‌ترین هدف Clean Architecture این است که قوانین و منطق اصلی کسب‌وکار مستقل از فریم‌ورک‌ها، کتابخانه‌ها و جزئیات پیاده‌سازی باقی بمانند. به همین دلیل، اپلیکیشن‌هایی که بر اساس این معماری توسعه داده می‌شوند، معمولاً تست‌پذیری بالاتر، نگهداری آسان‌تر و مقیاس‌پذیری بیشتری دارند و در پروژه‌های بلندمدت عملکرد بهتری از خود نشان می‌دهند.

لایه‌های معماری Clean

هسته اصلی Clean Architecture بر پایه جداسازی مسئولیت‌ها (Separation of Concerns) بنا شده است. در این معماری، هر لایه وظایف مشخصی را بر عهده دارد و تنها از طریق قراردادهای تعریف‌شده با سایر لایه‌ها ارتباط برقرار می‌کند. این رویکرد باعث می‌شود تغییرات در یک بخش از سیستم، کمترین تأثیر را بر سایر بخش‌ها داشته باشد و نگهداری پروژه در بلندمدت ساده‌تر شود.

در پروژه‌های اندرویدی، Clean Architecture معمولاً از سه لایه اصلی تشکیل می‌شود:

1. لایه Presentation

لایه Presentation نزدیک‌ترین بخش به کاربر است و مسئول نمایش داده‌ها و مدیریت تعاملات کاربر با اپلیکیشن می‌باشد. در پروژه‌های مدرن اندروید، این لایه معمولاً شامل Jetpack Compose یا XML، ViewModel و کلاس‌های مدیریت وضعیت (State Management) است.

وظیفه اصلی این لایه دریافت رویدادهای کاربر، ارسال درخواست‌ها به لایه Domain و نمایش نتایج دریافتی است. نکته مهم این است که لایه Presentation نباید شامل منطق اصلی کسب‌وکار باشد و تنها باید روی نمایش اطلاعات و مدیریت وضعیت رابط کاربری تمرکز کند.

لایه های معماری Clean Architecture در اندروید

اجزای رایج این لایه:

• Composable Screens یا Activities و Fragments
• ViewModel
• UI State
• UI Events
• Navigation

2. لایه Domain

لایه Domain مهم‌ترین بخش Clean Architecture محسوب می‌شود و قلب منطق کسب‌وکار (Business Logic) اپلیکیشن در این لایه قرار دارد. این لایه کاملاً مستقل از اندروید، فریم‌ورک‌ها، کتابخانه‌ها و منابع داده است.

در Domain معمولاً Use Caseها، مدل‌های دامنه (Domain Models) و قراردادهای Repository قرار می‌گیرند. این استقلال باعث می‌شود بتوان منطق اصلی برنامه را بدون وابستگی به رابط کاربری یا دیتابیس توسعه و تست کرد.

اجزای رایج این لایه:

• Use Cases
• Domain Models
• Repository Interfaces
• Business Rules

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

3. لایه Data

لایه Data مسئول تأمین و مدیریت داده‌های مورد نیاز برنامه است. این لایه اطلاعات را از منابع مختلف مانند API، پایگاه داده محلی، فایل‌ها، Cache یا سرویس‌های شخص ثالث دریافت کرده و در قالب مورد نیاز به لایه Domain ارائه می‌دهد.

در واقع Repositoryهایی که در لایه Domain به صورت Interface تعریف شده‌اند، در این لایه پیاده‌سازی می‌شوند. به همین دلیل Domain هیچ اطلاعی از نحوه دریافت داده‌ها ندارد و تنها با قراردادهای تعریف‌شده کار می‌کند.

اجزای رایج این لایه:

• Repository Implementations
• Remote Data Sources
• Local Data Sources
• Retrofit Services
• Room Database
• DTOs و Mappers

قانون وابستگی (Dependency Rule)

مهم‌ترین اصل در Clean Architecture قانون وابستگی است. طبق این قانون، وابستگی‌ها همیشه باید به سمت داخل حرکت کنند:

Presentation → Domain ← Data

به عبارت دیگر، لایه Domain نباید هیچ وابستگی مستقیمی به اندروید، Retrofit، Room، Compose یا هر تکنولوژی دیگری داشته باشد. این استقلال باعث می‌شود بتوان بدون تغییر منطق کسب‌وکار، رابط کاربری یا منبع داده را در آینده جایگزین کرد.

برای مثال، اگر امروز از Retrofit برای ارتباط با سرور استفاده می‌کنید و در آینده تصمیم بگیرید از کتابخانه دیگری استفاده کنید، تنها لایه Data تغییر خواهد کرد و هیچ تغییری در Domain و Presentation ایجاد نخواهد شد.

مزایای استفاده از معماری Clean در اندروید

استفاده از Clean Architecture در توسعه اپلیکیشن‌های اندرویدی مزایای زیادی دارد که شامل:

• افزایش خوانایی و نگهداری کد: جداسازی لایه‌ها باعث ساده‌تر شدن فهم کد و تغییرات در آینده می‌شود.
• بهبود تست‌پذیری: استقلال لایه‌های مختلف باعث می‌شود بتوان هر بخش را به‌صورت جداگانه تست کرد.
• کاهش وابستگی به فریمورک‌ها: به دلیل جداسازی لایه Domain، برنامه به تکنولوژی‌های خاصی وابسته نیست و به‌راحتی قابل مهاجرت به فریمورک‌های دیگر است.
• افزایش مقیاس‌پذیری: با تفکیک مسئولیت‌ها، توسعه‌دهندگان می‌توانند به‌صورت مستقل روی بخش‌های مختلف کار کنند.
• استفاده از اصول SOLID: این معماری بر پایه اصول SOLID طراحی شده که باعث افزایش انعطاف‌پذیری و کیفیت کد می‌شود.

مقایسه معماری Clean و MVVM

در حالی که MVVM (Model-View-ViewModel) یکی از پرکاربردترین معماری‌ها در توسعه اندروید است، Clean Architecture ساختاری جامع‌تر و منظم‌تر ارائه می‌دهد. در ادامه برخی از تفاوت‌های کلیدی این دو معماری آورده شده است:

در کل، معماری MVVM برای پروژه‌های کوچک تا متوسط مناسب است، در حالی که Clean Architecture برای پروژه‌های بزرگ‌تر و پیچیده‌تر توصیه می‌شود.

نحوه عملکرد معماری Clean Architecture در اندروید

این معماری از چندین لایه مستقل تشکیل شده است که هر کدام وظایف مشخصی دارند:

1. لایه Domain: شامل منطق کسب‌وکار (Business Logic) و اینترفیس‌های مربوط به داده است. این لایه هیچ وابستگی به فریمورک‌های اندرویدی ندارد.
2. لایه Data: مسئول دسترسی به داده‌ها از منابع مختلف (API، دیتابیس، کش و غیره) است. این لایه اطلاعات را به لایه Domain ارسال می‌کند.
3. لایه Presentation: شامل ViewModel و UI است که با داده‌ها تعامل دارد و آن‌ها را به کاربر نمایش می‌دهد.

مثال عملی با معماری Clean Architecture در اندروید

در این مثال، اطلاعات مربوط به کاربران را از طریق API دریافت کرده و در یک لیست نمایش می‌دهیم.

1. افزودن وابستگی‌ها به build.gradle

implementation 'com.squareup.retrofit2:retrofit:2.9.0'
implementation 'com.squareup.retrofit2:converter-gson:2.9.0'
implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.5.1'

2. ایجاد مدل داده (Data Model)

data class User(
    val id: Int,
    val name: String,
    val username: String,
    val email: String
)

3. تعریف اینترفیس API

interface ApiService {
    @GET("users")
    suspend fun getUsers(): List<User>
}

4. پیاده‌سازی Repository

class UserRepository(private val apiService: ApiService) {
    suspend fun getUsers(): List<User> = apiService.getUsers()
}

5. پیاده‌سازی ViewModel

class UserViewModel(private val repository: UserRepository) : ViewModel() {
    private val _users = MutableLiveData<List<User>>()
    val users: LiveData<List<User>> get() = _users

    fun fetchUsers() {
        viewModelScope.launch {
            _users.value = repository.getUsers()
        }
    }
}

6. پیاده‌سازی UI در Activity

class MainActivity : AppCompatActivity() {
    private lateinit var viewModel: UserViewModel
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        
        viewModel = ViewModelProvider(this).get(UserViewModel::class.java)
        viewModel.fetchUsers()
        
        viewModel.users.observe(this) { users ->
            // نمایش اطلاعات در UI
        }
    }
}

نتیجه‌گیری

معماری Clean Architecture یکی از محبوب‌ترین و استانداردترین رویکردهای طراحی نرم‌افزار در توسعه اپلیکیشن‌های اندرویدی است که با هدف جداسازی مسئولیت‌ها، کاهش وابستگی بین بخش‌های مختلف برنامه و افزایش قابلیت نگهداری پروژه طراحی شده است. این معماری به توسعه‌دهندگان کمک می‌کند تا منطق کسب‌وکار را از جزئیات پیاده‌سازی مانند رابط کاربری، پایگاه داده و سرویس‌های شبکه مستقل نگه دارند.

در پروژه‌های کوچک ممکن است استفاده از Clean Architecture در ابتدا پیچیده و زمان‌بر به نظر برسد، اما با افزایش مقیاس پروژه، تعداد اعضای تیم و پیچیدگی قابلیت‌ها، مزایای آن به‌وضوح قابل مشاهده خواهد بود. ساختار منظم، تست‌پذیری بالا، توسعه آسان‌تر قابلیت‌های جدید و امکان جایگزینی فناوری‌های مختلف بدون تأثیر بر منطق اصلی برنامه از مهم‌ترین دلایل محبوبیت این معماری در میان تیم‌های حرفه‌ای توسعه اندروید است.