binout/ten-tips-gs-ddd

Ten tips for getting started with domain driven design

10 conseils pour réussir ses premiers pas en DDD

Me

[twitter] @binout
[github] https://github.com/binout

• Développeur Java depuis plus de 10 ans

• Commiteur Asciidoctor (project lead asciidoctor-ant)

• Technical Leader chez Lectra, numéro un mondial des solutions dédiées à l’industrie du textile (machines et logiciels)

Domain Driven Design

Tackling Complexity in the Heart of Software

— Eric Evans
2003

Pourquoi DDD ?

• comprendre le domaine métier

• réduire la complexité accidentelle pour se concentrer sur la complexité métier

• mieux communiquer avec les différents intervenants

Conseil 1

1) Lire Domain-Driven Design Vite fait

https://www.infoq.com/fr/minibooks/domain-driven-design-quickly

Conseil 2

2) Mettre le focus sur la modélisation du métier

• Permet de définir un vocabulaire (Ubiquitous Language)

• Bien réfléchir aux propriétés des entités

• Bien définir des agrégats

• Rester indépendant de tous composants techniques (persistence, sérialisation)

Exemple : Pokemon

Un Pokemon :

• A un type (pikachu)

• A un nom (par défaut type)

• A des PV (par défaut 100)

• Peut être nommé

• Peut évoluer

• Peut mourir …​

POJO : ce n’est pas un modèle !

link:src/main/java/domain/bad/Pokemon.java[role=include]

Constructeur et propriété

link:src/main/java/domain/Pokemon.java[role=include]

Métier dans le modèle

link:src/main/java/domain/Pokemon.java[role=include]

Conseil 3

• Commencer par une persistence en mémoire (hashmap) pour éviter de lier son domaine à des problèmatiques techniques

• Utiliser des UUIDs générés par l’application comme id

Conseil 4

4) S’appuyer sur une architecture hexagonale

http://alistair.cockburn.us/Hexagonal+architecture

Ports & Adapters

Dépendances dans l’hexagone

Conseil 5

5) La couche application doit définir des cas d’utilisation

• un cas d’utilisation → une classe avec une seule méthode

• pas d’appel entre deux services d’application

• permet d’écrire des tests indépendamment du protocole de l’interface

Exemple : Evolution Pokemon

link:src/main/java/application/EvolvePokemon.java[role=include]

Exemple : Catch Pokemon

link:src/main/java/application/CatchPokemon.java[role=include]

Conseil 6

6) Bien comprendre la notion de service

• Service d’applications : cas d’utilisation

• Service d’infrastructure : communication avec les systèmes externes

• Service du domaine : règle métier partagée entre deux cas d’utilisation

Exemple : Domain Service

link:src/main/java/domain/PokemonStatsCalculation.java[role=include]

Conseil 7

7) Living Documentation FTW !

• Annotations :

  • @DDD.Entity, @DDD.Repository, @DDD.DomainService, …​

• Générer un diagramme du domaine à partir des sources

• Générer un diagramme des dépendances de l’architecture hexagonale

Conseil 8

8) Se débarrasser de ses à-priori de développeur !

• Des habitudes de développement liées à notre apprentissage des frameworks…​

• Le plus important c’est le métier pas la technique !

Exemple : Annotation JPA

public class Pokemon {

    @Id
    private final String id;
    @Embedded
    @AttributeOverrides({
        @AttributeOverride(name="value", column=@Column(name="TYPE"))
    })
    private final PokemonType type;
    @Column(name = "name", columnDefinition = "VARCHAR(255)")
    private String name;
    @Column(name = "pv",length=2, nullable = false)
    private int pv;
    ....
}

XML configuration !

• Mapping JPA par annotations pollue le domaine

• Utilisation de META-INF/orm.xml

  • moyen de sortir le framework du domaine

  • tout aussi facile à écrire et à maintenir

  • support dans l’ide

Conseil 9

9) Faire des tests d’intégration en utilisant le Behavior Driven Development

• Permet de manipuler le domaine dans les tests (fichier feature)

Exemple de feature

Scenario: Catch a pokemon
   Given a pikachu with PV=512
   When you give a cloudberry
     And you throw a pokeball
   Then the pikachu is caught
     And you win 500 XP

Conseil 10

10) Impliquer son Product Owner

• Lui expliquer les concepts, la démarche

• Lui montrer le modèle

• Lui demander si le vocabulaire lui parle

• Lui montrer les tests BDD

• Lui demander de les écrire ;-)

Conclusion : Not a silver bullet but …​

• Permet de passer une étape dans votre parcours de développeur !