Architecture évolutive pour les grandes applications mobiles

Dans cet article, nous n'analyserons pas MVP, MVVM, MVI ou quelque chose comme ça. Aujourd'hui, nous allons parler d'une chose plus globale que la simple architecture au niveau de la présentation. Comment concevoir une très grande application dans laquelle des dizaines ou des centaines de développeurs peuvent travailler confortablement? Une application facile à étendre, quelle que soit la quantité de code que nous avons écrite.

Exigences pour les grands projets:

1. Connectivité de code faible. Toute modification doit affecter le moins de code possible.
2. Réutilisation du code. Les choses identiques devraient être faciles à réutiliser sans copier-coller.
3. Facilité d'expansion. Il devrait être facile pour un développeur d'ajouter de nouvelles fonctionnalités au code existant.
4. La stabilité. Tout nouveau code peut être facilement désactivé à l'aide des bascules de fonctionnalités , surtout si vous utilisez un développement basé sur des troncs .
5. Propriété du code. Le projet doit être divisé en modules, de sorte qu'il serait facile d'attribuer un propriétaire pour chaque module. Cela nous aidera dans la phase de révision du code. Et ici non seulement sur les grandes choses, comme les modules Gradle / Pods, mais aussi sur les fonctionnalités ordinaires, qui peuvent avoir des propriétaires différents .

Composant

. - (MV*) Presenter/ViewModel/Interactor/- . , - - . , , , // . , -, .

, . .

1. . - .
2. . .
3. . .
4. . , , .
5. UI. .
6. Unidirectional data flow . .
7. . feature toggles.
   , , , . , - .

1. (DomainObject).
2. (UI State).
3. .
4. - ( , ), (Action) , . UI State, (Action) , Service. Service (. 1).

, , (Actions) (Service). Service (DomainObjects) . Service - : UserService, PaymentsService, CartService, : ProductDetailsService, OrderService.

, , MVP/MVC/MVVM/MVI , ().

 —  , , , , .

:

• Middleware —  (Actions). , Middleware . .
• Reducer —  Middleware. .

, Middleware Reducer , Middleware Reducer.
: Flux, Redux, MVI

Server Drive UI

, (DomainObject), . Play Store/App Store. , !

Du serveur, nous pouvons recevoir une liste de composants sur l'écran indiquant leur type, leur position sur l'écran, leur version et les données nécessaires au fonctionnement et à l'affichage.

{
  "components": [
    {
      "type": "toolbar",
      "version": 3,
      "position": "header",
      "data": {
        "title": "Profile",
        "showUpArrow": true
      }
    },
    {
      "type": "user_info",
      "version": 1,
      "position": "header",
      "data": {
        "id": 1234,
        "first_name": "Alexey",
        "last_name": "Glukharev"
      }
    },
    {
      "type": "user_photo",
      "position": "header",
      "version": 2,
      "data": {
        "user_photo": "https://image_url.png"
      }
    },
    {
      "type": "menu_item",
      "version": 1,
      "position": "content",
      "data": {
        "text": "open user details",
        "deeplink": "app://user/detail/1234"
      }
    },
    {
      "type": "menu_item",
      "version": 1,
      "position": "content",
      "data": {
        "text": "contact us",
        "deeplink": "app://contact_us"
      }
    },
    {
      "type": "button",
      "version": 1,
      "position": "bottom",
      "data": {
        "text": "log out",
        "action": "log_out"
      }
    }
  ]
}

Des questions?

J'ai participé au développement de plusieurs grands projets utilisant cette architecture, et je suis ouvert à la fois aux questions sur l'architecture en général et aux détails techniques de l'implémentation Android.