Agile Tour Québec 2019 - DDD et programmation fonctionnelle : des alliés naturels

La popularité du DDD est à la hausse dans les dernières années avec la montée des microservices et dans un contexte d’architecture évolutive Agile. Lorsqu’on pense au sujet du Domain-Driven Design, on pense naturellement à une implémentation dans un langage orienté objet. Mais, peut-on imaginer des Bounded Contexts et des Shared Kernels lorsque nous utilisons un paradigme axé sur les fonctions? C’est ce que vous apprendrez dans cette présentation.

Transcript

1. DDD et programmation fonctionnelle Des alliés naturels Agile Tour Québec - 29 octobre 2019
2. Olivier Lafleur, M.Sc., PSM Coach agile / technique Professeur @olilafleur
3. Qui sait ce qu’est le DDD ?
4. Qui a déjà fait de la programmation fonctionnelle?
5. La communication entre clients, devs et gens d’affaires peut être problématique Développeurs Experts du domaine d’affaires
7. BDD Given … When … Then …
9. Langage commun (ubiquitous) Facture Talon de paie Reçu Commande Développeurs Experts du domaine d’affaires
10. Séparer les contextes (bounded contexts)
11. Modéliser les règles d’affaires, en faisant abstraction de la plateforme
12. Quand ne pas utiliser le DDD ?
13. Quand ne pas utiliser le DDD ?
14. Peut-on viser une documentation exécutable (i.e. du code) lisible par des gens d’affaires ? Oui !
15. C’est quoi une bonne architecture?
19. Architecture hexagonale
22. Mais où est la programmation fonctionnelle là-dedans ?
23. Remerciements - Jean-François Bourget Danger / Chaos Bordure / Mapping Confortable / Sécure
25. En fonctionnel, on modélise avec des types et des fonctions.
26. type Sorte = Coeur | Trèfle | Pique | Carreau type Face = Deux | Trois | Quatre | Cinq | Six | Sept | Huit | Neuf | Dix | Valet | Dame | Roi type Carte = { sorte: Sorte face: Face } type Main = Carte list
27. Avez-vous détecté l’erreur dans le code?
28. type Sorte = Coeur | Trèfle | Pique | Carreau type Face = Deux | Trois | Quatre | Cinq | Six | Sept | Huit | Neuf | Dix | Valet | Dame | Roi | As type Carte = { sorte: Sorte face: Face } type Main = Carte list
29. A language that doesn’t affect the way you think about programming is not worth knowing. — Alan Perlis
31. Une fonction, c’est quoi? Banane Pomme →
32. Un tunnel de transformation Banane Pomme →
33. Aucun effet “extérieur” Banane Pomme →
34. En F#, tout est une fonction : let carré x = x * x // signature int -> int let grandeur = 6 // signature unit -> int let addition x y = x + y // signature (int, int) -> int
35. Même si les types sont implicites, ils sont plus “forts” que dans certains langages populaires.
36. int string → Un exemple de fonction qui a cette signature?
37. string int → Un exemple de celle-ci?
38. bool bool → Combien existe-t-il de fonctions qui ont cette signature?
39. → → true true false false → → true false false true → → true true false true → → true false false false Identité NOT True False
40. Modélisation
41. type SaladeDeFruits = { Pomme: VariétéDePomme Banane: VariétéDeBanane Cerise: VariétéDeCerise } La composition de types
42. type SaladeDeFruits = { Pomme: VariétéDePomme Banane: VariétéDeBanane Cerise: VariétéDeCerise } C’est un ET, une combinaison de plusieurs éléments La composition de types
43. type VariétéDePomme = | GoldenDelicious | GrannySmith | Fuji type VariétéDeBanane = | Cavendish | GrosMichel | Manzano
44. type VariétéDePomme = | GoldenDelicious | GrannySmith | Fuji type VariétéDeBanane = | Cavendish | GrosMichel | Manzano C’est un OU, le choix entre plusieurs éléments
45. Pattern matching
46. let imprimerTypePomme variete = match variete with | GoldenDelicious -> printfn "Une Golden Delicious" | GrannySmith -> printfn "Une Granny Smith" Par exemple : ne compile pas !
47. let imprimerTypePomme variete = match variete with | GoldenDelicious -> printfn "Une Golden Delicious" | GrannySmith -> printfn "Une Granny Smith" | Fuji -> printfn "Une Fuji" Par exemple :
48. Et parfois aussi un choix simple type CodeDeProduit = | CodeDeProduit of string // ou type CodeDeProduit = CodeDeProduit of string
49. types simples null
50. Mais alors, comment on représente un champ “nullable” ou plus généralement, le concept d’absence?
52. Ok, mais est-ce que tout ça est utilisable dans la vraie vie?
53. Modélisation d’un cas réaliste
54. Le paiement d’une facture Pour le paiement, on veut : - un montant - une devise - une méthode de paiement.
55. Le montant du paiement type MontantPaye = MontantPaye of decimal // emballage type Devise = EUR | USD | CDN // type "OU"
56. La méthode de paiement type NoCheque = NoCheque of int type NoCarte = NoCarte of string type TypeCarte = Visa | Mastercard type InfoCarteCredit = { TypeCarte: TypeCarte NoCarte: NoCarte } type MéthodePaiement = | Comptant | Chèque of NoCheque | CarteCredit of InfoCarteCredit
57. Le paiement comme tel type Paiement = { Montant: MontantPaye Devise: Devise Méthode: MéthodePaiement }
58. Le consommateur type Consommateur = { Prénom: string DeuxièmeNom: string NomDeFamille: string }
59. Le consommateur type Consommateur = { Prénom: string DeuxièmeNom: string NomDeFamille: string } Comment rendre le deuxième nom facultatif?
60. Le consommateur type Consommateur = { Prénom: string DeuxièmeNom: Option<string> // ou DeuxièmeNom: string option NomDeFamille: string }
61. La modélisation du processus de paiement
62. Machine à états (automate)
63. Un item type Item = ??? type DonneesPanierActif = { ItemsNonPayes: Item list } type DonneesPanierPaye = { ItemsPayes: Item list; Paiement: Paiement } type Panier = | PanierVide | PanierActif of DonneesPanierActif | PanierPaye of DonneesPanierPaye
64. Ajouter un item let ajouterItem panier item = match panier with | PanierVide -> // créer un nouveau panier actif avec un item PanierActif { ItemsNonPayes = [item] } | PanierActif { ItemsNonPayes = itemsExistants } -> // créer un nouveau panier avec l'item ajouté PanierActif { ItemsNonPayes = item :: itemsExistants } | PanierPaye _ -> // on ignore panier
65. Faire un paiement let fairePaiement panier paiement = match panier with | PanierVide -> panier | PanierActif { ItemsNonPayes = itemsExistants } -> PanierPaye { ItemsPayes = itemsExistants; Paiement = paiement } | PanierPaye _ -> panier
66. Comment gérer les erreurs dans ce monde “parfait” ?
67. En étant explicite type ErreurValidationAdresse = ErreurValidationAdresse of string type VérifieAdresseExiste = AdresseNonValidée -> Result<AdresseVerifiee, ErreurValidationAdresse>
68. Et l’injection de dépendances?
69. En orienté objet : classes sont passés en paramètres / injectés En fonctionnel : ce sont des fonctions ayant certain types qui sont passées en paramètres
70. Et les tests unitaires? Sont-ils encore nécessaires?
71. Oui !
72. Quelques liens avec le DDD - Value Objects - Agrégats - Événements du domaine - Bounded contexts - etc.
73. Ok, mais demain matin je fais quoi?
74. Interopérabilité - Appeler du F# dans un projet C# - Appeler du C# dans un projet F#
76. Et avec d’autres langages?
77. Et ces langages?
79. Conclusion DDD et programmation fonctionnelle : des alliés naturels?
80. Merci pour votre écoute !
81. Questions? Discussions?