XebiCon'18 - Architecturer son application mobile pour la durabilité

@Xebiconfr #Xebicon18 @pjechris
Build the future
Architecturer son application mobile
sur la durée
Jean-Christophe Pastant
1

Qui suis-je ?
Jean-Christophe Pastant
iOS Developer/Architect
Xebia IT Architects
@pjechris
2

Une architecture n’a pas besoin d’être complexe
pour être réussie
3

Architecturer ?
4

Bonne architecture ?
5

Bonne architecture ?
● Orientée vers le besoin fonctionnel
● Construite pour le présent (Pragmatique)
● Lisible (Simple)
● Cohérente (Simple, Pragmatique)
6

Architecture pérenne ?
7

Architecture pérenne ?
● Robuste dans le temps (petites modifications)
● Évolutive dans le temps (grosses modifications)
8

Architecturer ?
Une bonne architecture pérenne se doit d’être :
● Simple
KEEP IT SIMPLE, STUPID
● Pragmatique
YOU AIN’T GONNA NEED IT
● Fonctionnelle/métier
DOMAIN DRIVEN DESIGN
● Modifiable/évolutive
SEPARATION OF CONCERN, OPEN/CLOSED PRINCIPLE
9

Structurer
en couches
Keep it simple, You ain’t gonna need it, Domain Driven Design, Separation of Concern

Structurer en couches permet de :
● Séparer les responsabilités
○ Affichage
○ Appels réseaux
○ ….
● Réfléchir quel rôle (couche) joue une classe
● Être plus ouvert aux changements
○ On est agnostique des couches supérieures
Structurer en couches
11

Données
Métier
UI
DB WS Cache
login
logout
checkout
addBook
Layout i18n Formatting
12

Données
Métier
UI
DB WS Cache
login
logout
checkout
addBook
Layout i18n Formatting
Modèles
métier
13

Modèles métier
14
Keep it simple, Domain Driven Design

Exemple
● Pouvoir ajouter des livres dans un panier
● Afficher le panier
● Afficher le prix total du panier
source : application Fnac (Android)
15

Modèles métier
struct Book {
let id: Int
let isbn: String
let title: String
let price: Float
}
16

Modèles métier
import ReactiveKit
struct Cart {
private(set) var books: [Book]
var total: Observable<Float>
mutating func add(book: Book) { }
mutating func remove(index: Int) { }
}
17

Modèles métier
import ReactiveKit
struct Cart {
var total: Float
mutating func remove(index: Int) { }
}
18

Modèles métier
struct Cart {
var total: Float
mutating func remove(book: Book) { }
}
19

Modèles métier
● Notion centrale du métier/fonctionnel dans l’application
● Donne du sens dans la communication entre les couches
● Doit être orienté métier
● Objets simples
○ Immutables
○ Pas de réseau, pas d’asynchrone, etc...
20

UI
“Dumb components”
Keep it simple, Domain Driven Design, Open/Closed principle

Exemple
Application Fnac (Android)
CartItemView
priceLabel
title
22

Exemple
Application Fnac (Android)
CartItemView
23
CartRecapView

UI
class CartItemView: UIView {
var priceLabel: UILabel!
var title: UILabel!
func configure(title: String, price: String) {
priceLabel.text = price
title.text = title
}
}
24

UI
var title: UILabel!
func configure(title: String, price: String) {
title.text = title
}
}
class CartRecapView: UIView {
func configure(price: String) {
}
}
25

UI
var title: UILabel!
func configure(book: Book) {
title.text = title
}
}
func configure(cart: Cart) {
}
}
26

UI
var title: UILabel!
priceLabel.text = stringify(book.price, .currency)
title.text = book.title.uppercased
}
}
priceLabel.text = stringify(cart.total, .currency)
}
}
27

UI
struct PriceComponent {
func bind(price: Float, label: UILabel) {
}
}
28

UI
label.text = stringify(price, style: .currency)
}
}
29

UI
label.text = stringify(price, style: .currency)
}
}
struct TitleComponent {
func bind(title: String, label: UILabel) {
label.text = title.capitalize
}
}
30

UI
var title: UILabel!
priceLabel.text = stringify(book.price, .currency)
title.text = book.title.uppercased
}
}
priceLabel.text = stringify(cart.total, .currency)
}
}
31

UI
var title: UILabel!
priceLabel.bind(book.price, with: PriceComponent.self)
title.bind(book.title, with: TitleComponent.self)
}
}
priceLabel.bind(cart.total, with: PriceComponent.self)
}
}
32

UI
● Faire des petits composants UI réutilisables
● Préférer combiner les composants plutôt que l’héritage
● Exposer une API métier
33

Métier
“Smart components”
Keep it simple, You ain’t gonna need it, Domain Driven Design

Métier
class CartComponentContext {
// API
private(set) var cart: Variable<Cart>
let checkoutAction: Action
}
35

Métier
// API
private let httpRepository: XebiaWSRepository
init(cart: Cart) {
self.cart = cart
self.httpRepository = XebiaWSRepository(...)
}
}
36

Métier
// API
init(cart: Cart) {
self.cart = cart
self.checkoutAction = Action(
enabledIf: { !cart.isEmpty },
factory: { httpRepository.checkout(self.cart) })
}
}
37

Métier
● Lien entre la couche données et la couche UI
● Définissent les actions / règles métier
○ Passer une commande seulement si le panier n’est pas vide
○ …
● Font les appels réseaux
● Gérent les états
● Exposent une API métier
38

Données
39
Keep it simple, Separation of Concern

Données
class XebiaWSRepository {
func checkout(cart: Cart, success: (Void) -> (), failure:
(Error) -> ()) {
}
40

Données
(Error) -> ()) {
let url = URL(string: “…”)
SessionManager.default.request(url).responseJSON {
}
}
41

(Error) -> ()) {
let url = URL(string: “…”)
SessionManager.default.request(url).responseJSON {
let json = JSON(data: $0.jsonData)
do {
let books = try JSONDecoder().decode([Book].self,
from: jsonData)
success(books)
}
catch let error { failure(error) }
}
}
42

Données
func checkout(cart: Cart) -> Promise<Void> {
}
}
43

Données
let builder: HttpQueryBuilder<XebiaEndpoint>
return builder.query(.checkout(cart)).request()
}
}
44

Données
let builder: HttpQueryBuilder<XebiaEndpoint>
return builder.query(.checkout(cart)).request()
}
func findBooks() -> Promise<[Book]> {
return builder.query(.books).request()
}
}
45

Données
● Doit être simple mais fiable et lisible
● Stateless
● Mapping 1-to-1 avec les services fournies
○ 1 classe = 1 service (DB, WS, …)
○ 1 méthode = 1 API
46

Providers
47
Separation of Concern

Providers
class CartProvider {
let httpRepository: XebiaWSRepository
return httpRepository
.checkout(cart)
}
}
48

Providers
class CartProvider {
let httpRepository: XebiaWSRepository
let realmRepository: RealmRepository
return httpRepository
.checkout(cart)
.then { realmRepository.savePurchasedCart($0) }
}
}
49

Providers
// API
init(cart: Cart) {
self.cart = cart
factory: { httpRepository.checkout(self.cart) })
}
}
50

Providers
// API
private let cartProvider: CartProvider
init(cart: Cart) {
self.cart = cart
self.cartProvider = CartProvider(...)
factory: { cartProvider.checkout(cart: self.cart) })
}
}
51

Providers
● Facilite la synchronisation/les accès à plusieurs Repository
● Réduit la logique dans les Smart Components
● 1 classe par objet métier (BookProvider, CartProvider, …)
52

Injection de dépendances
53
Keep it simple, Separation of Concern

// API
init(cart: Cart) {
self.cart = cart
self.cartProvider = CartProvider(...)
}
}
54

// API
init(cart: Cart, cartProvider: CartProvider) {
self.cart = cart
self.cartProvider = cartProvider
}
}
55

● Aide à garder les couches indépendantes
● Limite la connaissance de chaque objet au strict minimum
● Permet de tester plus facilement
56

Tests unitaires
57

Tests unitaires
Tester doit être simple
Si :
● Vous écrivez trop de lignes pour un test (+ 10 lignes)
● C’est trop compliqué de tester malgré tous vos protocoles/interfaces
Revoyez votre architecture !
58

We did it!
59

We did it!
● Simple
Petites classes, code réutilisable, séparation des rôles
● Pragmatique
Code incrémental, isolation des rôles
● Fonctionnelle/métier
APIs orientées modèles métier
● Modifiable/évolutive
Structure en couches, injection de dépendances, principes SOLID
60

MERCI
Questions ?

XebiCon'18 - Architecturer son application mobile pour la durabilité

Contenu connexe

Tendances (8)

Similaire à XebiCon'18 - Architecturer son application mobile pour la durabilité (20)

Plus de Publicis Sapient Engineering (20)

XebiCon'18 - Architecturer son application mobile pour la durabilité