Ինչ կարող եք ասել մաքուր ճարտարապետության մասին?

Անաքարային ճարտարապետություն (Clean Architecture), որը հանրաճանաչ է դարձել Ռոբերտ Մարտինի ("Տատիկ Բոբ") կողմից, ներկայացնում է սկզբունքների հավաքածու՝ կոդի կազմակերպման համար, որոնք ուղղված են ճկուն, թեստավորելի և հեշտ սպասարկվող համակարգ ստեղծելուն:

Հիմնական գաղափարներ:

1. Շերտերի բաժանում: Կոդը բաժանվում է կոնցենտրիկ շրջանների՝ ներքին շրջանները պարունակում են բիզնես տրամաբանությունը, իսկ արտաքինները՝ իրականացման մանրամասները (UI, տվյալների բազաներ, արտաքին API):
2. Արտաքին շերտերի կախվածությունը ներքինից: Արտաքին շերտերը կախված են ներքինից, բայց ոչ հակառակը: Սա հասնում է կախվածությունների հակադարձման սկզբունքով:
3. Զտվածություն: Յուրաքանչյուր շերտ թաքցնում է իր իրականացման մանրամասները արտաքին շերտերից:
4. Թեստավորելիություն: Կենտրոնական շերտերում գտնվող բիզնես տրամաբանությունը չի կախված արտաքին մանրամասներից, ինչը հեշտացնում է նրա թեստավորումը մեկուսացված:
5. Ազատություն ֆրեյմվորկներից: Բիզնեսի հիմնական կանոնները կապված չեն կոնկրետ ֆրեյմվորկների, UI կամ տվյալների բազաների հետ:

Շերտեր (մատուկ օրինակ):

• Entities: պարունակում են բիզնես օբյեկտներ և կանոններ (օրինակ, դաս User՝ բիզնես տրամաբանությամբ, կապված օգտատիրոջ հետ):
• Use Cases (Interactors): պարունակում են հատուկ հավելվածի բիզնես տրամաբանությունը (օրինակ, GetUserUseCase):
• 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 ֆրեյմվորկների կամ գրադարանների հետ:

Անբավարարություններ:

• Կարծրություն: Միգուցե սկզբում ավելի բարդ լինի հասկանալ և իրականացնել, հատկապես փոքր նախագծերի համար:
• Կոդի ավելացում: Պահանջում է ավելի շատ դասեր և ինտերֆեյսներ գրել, քան ավելի պարզ ճարտարապետություններում:

Ընդհանուր առմամբ, Clean Architecture-ը հզոր մոտեցում է մոդուլային և սպասարկվող Android հավելվածներ ստեղծելու համար, հատկապես միջին և մեծ բարդության նախագծերի համար: Այն խթանում է բիզնես տրամաբանության շուրջ զարգացումը, ոչ թե տեխնիկական մանրամասների։