რა შეგიძლიათ თქვათ სუფთა არქიტექტურის შესახებ?

სუფთა არქიტექტურა (Clean Architecture), რომელიც პოპულარიზებული იყო რობერტ მარტინმა ("ძია ბობმა"), წარმოადგენს პრინციპების კრებულს კოდის ორგანიზაციისთვის, რომელიც მიმართულია მოქნილი, ტესტირებადი და ადვილად შენარჩუნებადი სისტემის შექმნისკენ.

ძირითადი იდეები:

1. საფეხურების განყოფილება: კოდი ნაწილდება კონცენტრიკულ წრედ, სადაც შიდა წრეები შეიცავს ბიზნეს ლოგიკას, ხოლო გარე — რეალიზაციის დეტალებს (UI, მონაცემთა ბაზები, გარე API-ები).
2. შიდა ფენის დამოკიდებულება: გარე ფენები დამოკიდებულია შიდა ფენებზე, მაგრამ არა პირიქით. ეს მიღწეულია დამოკიდებულებების ინვერსიის პრინციპით.
3. ინკაფსულაცია: თითოეული ფენა მალავს თავის რეალიზაციის დეტალებს გარე ფენებისგან.
4. ტესტირებადი: ცენტრალურ ფენებში მყოფი ბიზნეს ლოგიკა არ დამოკიდებულია გარე დეტალებზე, რაც მას ხდის მარტივ ტესტირებად იზოლაციაში.
5. ტექნოლოგიიდან დამოუკიდებლობა: ძირითადი ბიზნეს წესები არ არის დაკავშირებული კონკრეტულ ფრეიმვორკებს, UI-ს ან მონაცემთა ბაზებს.

ფენები (მაგალითი):

• Entities: შეიცავს ბიზნეს ობიექტებს და წესებს (მაგალითად, კლასი User ბიზნეს ლოგიკით, დაკავშირებული მომხმარებელთან).
• Use Cases (Interactors): შეიცავს კონკრეტულ ბიზნეს ლოგიკას აპლიკაციისთვის (მაგალითად, GetUserUseCase). ისინი კოორდინირებენ ურთიერთქმედებას Entities-სა და Gateway ინტერფეისებს შორის.
• Interface Adapters: ადაპტირებს მონაცემებს გარე წყაროებიდან ფორმატში, რომელიც გასაგებია Use Cases-სა და Entities-სთვის (მაგალითად, Presenter-ები UI-სთვის, Gateway-ის იმპლემენტაციები მონაცემთა ბაზებისთვის).
• Frameworks & Drivers: გარე ფენა, რომელიც შეიცავს ფრეიმვორკებს (UI, მონაცემთა ბაზები, ვებ სერვისები).

დამოკიდებულებების ინვერსიის პრინციპი თამაშობს მნიშვნელოვან როლს. შიდა ფენები განსაზღვრავენ ინტერფეისებს (Gateway Interfaces), ხოლო გარე ფენები ამ ინტერფეისებს რეალიზებენ. ეს წარმოდგენილია შემდეგ სქემაზე:

+-----------------+      +-------------------+      +--------------------+      +------------------------+
| Frameworks &    |----->|   Interface       |<-----|    Use Cases       |<-----|        Entities          |
| Drivers (UI, DB)|      |   Adapters        |      |  (Interactors)     |      |      (Business Rules)    |
+-----------------+      |  (Presenters,     |      |                    |      +------------------------+
                         |  Gateway Impls)   |      |                    |
                         +-------------------+      +--------------------+

სლაიდერები აჩვენებს დამოკიდებულებების მიმართულებას. ყველა დამოკიდებულება მიმართულია შიგნით, Entities ფენისკენ.

Android-ის განვითარებაში, სუფთა არქიტექტურა ხშირად რეალიზდება შემდეგ კომპონენტების გამოყენებით:

• UI Layer (Presentation): Activity, Fragment, ViewModel, UI ლოგიკა. დამოკიდებულია Domain Layer-ზე.
• Domain Layer (Use Cases): აპლიკაციის ბიზნეს ლოგიკა. არ არის დამოკიდებული სხვა ფენებზე.
• Data Layer: მონაცემთა წყაროები (სატელეფონო, მონაცემთა ბაზები), რეპოზიტორები. რეალიზებს Domain ფენაში განსაზღვრულ ინტერფეისებს.

მაგალითი სტრუქტურა:

root
├── app
│   ├── src
│   │   └── main
│   │       └── java
│   │           └── com
│   │               └── example
│   │                   └── myapp
│   │                       ├── presentation  // UI ფენა (ViewModel, Activities, Fragments)
│   │                       │   ├── ui
│   │                       │   └── viewmodel
│   │                       ├── domain      // დომენური ფენა (Use Cases, Entities, Interfaces)
│   │                       │   ├── entity
│   │                       │   ├── repository  // დომენური ინტერფეისები
│   │                       │   └── usecase
│   │                       └── data        // მონაცემთა ფენა (რეპოზიტორები, Data Sources, Mappers)
│   │                           ├── local       // ადგილობრივი Data Source (Room)
│   │                           ├── remote      // შორეული Data Source (Retrofit)
│   │                           ├── mapper
│   │                           └── repository  // Data რეალიზაციები, რომლებიც გრძელდება დომენურ ინტერფეისებს
│   └── build.gradle
└── build.gradle

უპირატესობები:

• ტესტირებადი: ბიზნეს ლოგიკა იზოლირებულია და მარტივია მისი ტესტირება.
• გააქტიურება: მარტივია გარე დამოკიდებულებების შეცვლა (მაგალითად, გადართვა Room-დან Realm-ზე).
• მოწყობა: პასუხისმგებლობების მკაფიო განაწილება ამარტივებს კოდის გაგებას და შენარჩუნებას.
• ტექნოლოგიიდან დამოუკიდებლობა: ბიზნეს ლოგიკა არ არის დაკავშირებული კონკრეტულ Android ფრეიმვორკებს ან ბიბლიოთეკებს.

მოხერხებულობები:

• სირთულე: თავდაპირველად შეიძლება იყოს უფრო რთული გასაგები და განხორციელება, განსაკუთრებით მცირე პროექტებისთვის.
• კოდის გაზრდა: მოითხოვს მეტი კლასის და ინტერფეისის დაწერას, შედარებით მარტივ არქიტექტურებთან.

საერთო ჯამში, სუფთა არქიტექტურა არის ძლიერი მიდგომა მასშტაბური და შენარჩუნებადი Android აპლიკაციების შექმნისთვის, განსაკუთრებით საშუალო და დიდი სირთულეების პროექტებისთვის. ის ხელს უწყობს ბიზნეს ლოგიკის გარშემო განვითარებას, არა ტექნიკური დეტალების გარშემო.