Publié par
Il y a 5 années · 1 minute · Craft, Java / JEE

Lien entre le fonctionnel, l’objet et le DDD

Dans la troisième partie de la soirée Vue d’ensemble du DDDJérémie Grodziski nous explique quels sont les liens entre le Domain Driven Design et les paradigmes fonctionnel et orienté objet. On a souvent tendance à assimiler l’approche DDD à la bonne manière de concevoir un système sous la forme de classes (orienté objet). C’est totalement juste. Cependant, on peut très bien envisager d’appliquer ces concepts avec un langage fonctionnel comme le montre un certain nombre d’arguments avancés dans cette vidéo :

Cette troisième partie a succédée à la présentation générale du DDD ainsi qu’à la vidéo détaillant ses principaux Building Blocs.

Sébastian Le Merdy

Sébastian est entré chez Xebia en 2011 pour mettre en pratique le Software Development Done Right.
Il est passionné par le développement logiciel et les technologies innovantes et le met au service de l’utilisateur final à travers l’agilité dans les projets.
Vous pourrez peut-être le rencontrer lors d’un coding dojo ou une présentation de live coding.

4 thoughts on “Lien entre le fonctionnel, l’objet et le DDD”

  1. Publié par yann degat, Il y a 5 années

    je me rappelle particulièrement d’un talk d’udi dahan que je serai bien incapable de retrouver. quoiqu’il devait s’agir du ddd exchange 2012 ou 2011.

    dans lequel il était fait état de la chose suivante :

    les objets n’existent que par leurs attributs. et donc, avant meme de chercher à nommer un objet ( et donc lui trouver une définition dans l’ubiquitous language ) il faut d’abord identifier l’ensemble des attributs nécessaires à l’accomplissement d’un use case / scenario bien précis.

    une fois qu’on a cette liste d’attributs, le nom de l’objet « valise » se révèle tout naturellement au travers d’un « Nom+Adjectif/Etat »

    ex : CommandeHistorisée, CommandeEnCours
    et surtout pas juste « Commande » comme on aurait eu le réflexe de le nommer au départ. Parce que du coup, de 2 Aggregates Root, on en conserve plus qu’un seul fourre tout et on foire alors complètement son DDD, son CQRS, sa SOA, son TDD, et tout un tas de trigrammes équivalents.

  2. Publié par Jérémie Grodziski, Il y a 5 années

    Bonsoir,

    @Yann : pour rebondir sur votre commentaire qui est très juste, un état peut être associé à un rôle qui influence alors le comportement de l’objet. Chaque rôle héberge un ensemble d’opérations. Ainsi une commande en cours peut être livrée (méthode « livrer »), payée (méthode « livrer ») mais une commande historisée peut uniquement être consultée et ne dispose pas de ces méthodes.

    La notion de mixin permet alors de composer un objet dynamiquement suivant le use-case qui s’exécute ((implémentation différente suivant les langages, qi4j en java émule cela, c’est built-in en javascript, clojure ou scala !). Cela autorise ainsi une vraie séparation des responsabilités et évite les objets « bouffis ».

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *