Il y a 10 ans -
Temps de lecture 1 minute
Lien entre le fonctionnel, l’objet et le DDD
Dans la troisième partie de la soirée Vue d’ensemble du DDD, Jé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.
Publié par 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.
Commentaire
4 réponses pour " Lien entre le fonctionnel, l’objet et le DDD "
Published by yann degat , Il y a 10 ans
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.
Published by yann degat , Il y a 10 ans
c’est peut etre bien çui là : http://skillsmatter.com/podcast/design-architecture/talk-from-udi-dahan
Published by Jérémie Grodziski , Il y a 10 ans
Bonsoir,
Merci à Xebia pour l’hébergement du meetup et la publication des vidéos.
Je viens de poster les slides et quelques liens ici : http://blog.zenmodeler.com/introduction-to-domain-driven-design-entity-and-value-object/
Bonne lecture,
Jérémie
Published by Jérémie Grodziski , Il y a 10 ans
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 ».