Souvent lorsque l’on parle de gérer les règles métiers, on pense à moteur de règle, pas forcement …
Le design pattern Specification est une solution de gestion de vos règles métiers.
Ce pattern a été formalisé par Eric Evans, père du DDD, et Martin Fowler que l’on ne présente plus.
Ce pattern est simple mais très puissant. Il permet de :
- marquer et identifier les règles métiers,
- les centraliser,
- les réutiliser,
- communiquer entre développeurs et fonctionnels sur ces règles métiers.
Cette solution a récemment été mise en place sur un gros site d’eCommerce en France. Je partage ici avec vous mon retour d’expérience, donc laissez vous convaincre !
Lire la suite de cet article »
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
RIA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »
En fin de matinée, nous avons eu une présentation Domain Driven Design et Value Objects (attention, ces VO là ne sont pas des DTO !). Cette présentation ne fait pas partie des révélations de Jazoon, néanmoins elle a fait preuve de bon sens, et ça on aime !
Comme la présentation, commençons par la conclusion. Evitez d’éparpiller la logique métier ou pire d’utiliser des règles de gestion implicites, utilisez notamment les Value Objects pour décrire la logique métier. Cela rend le code plus compréhensible et plus facile à tester.
Lire la suite de cet article »
Ce lundi 15 juin se tiendra une soirée exceptionnelle organisée par le Paris JUG dans les locaux de l’EPITA.
Une star mondiale de la conception logicielle, Eric Evans, nous présentera le DDD (Domain Driven Design).
Inscrivez-vous dès maintenant, les places sont limitées et prisées. Voici le plan d’accès à l’EPITA pour vous rendre à cet événement.
Voici le programme détaillé de la soirée :
19h15 : Accueil
19h30 à 21h00 : Domain Driven Design.
La présence d’Eric Evans sera l’occasion idéale pour répondre à toutes vos questions sur le DDD :
- Comment intégrer le DDD dans une organisation totalement étrangère à ces concepts ? Quels sont les angles d’attaque possible ?
- Quelles sont les bonnes pratiques pour construire l’ubiquitous language ?
- Des retours d’expérience sur les succès et échecs du DDD
- Les futures voies d’amélioration du DDD, notamment sur l’organisation de plusieurs équipes de développement
Pour rappel Xebia avait réalisé un article sur cette manière de concevoir les logiciels : DDD – La conception qui lie le fonctionnel et le code.
Saluons le Paris JUG pour l’organisation de ce genre d’évènements et le service relation entreprises de l’EPITA pour leur réactivité.
Références à ne pas manquer à propos du DDD :
Le DDD, Domain Driven Design, laisse une impression qui amène souvent à une des remarques suivantes :
- J’en ai déjà entendu parlé … – (mais je ne sais pas ce que c’est)
- Je crois l’avoir vu dans le TDD …
- C’est comme le MDA? – ça marche avec un ensemble de sigles MDSD, MDD
- Hein? T’as un problème avec ta touche « D »
L’objectif de cet article est de vous présenter le DDD, ses enjeux et son intérêt.
Dans DDD, il y a Driven Design, c’est donc une technique de conception. Il ne faut pas confondre avec les techniques de développement (Driven Development) comme par exemple le TDD (Test Driven Development).
DDD n’est ni une méthode ni une technologie. DDD est une manière de penser la conception autour du code, de collaborer et de communiquer avec les experts fonctionnels.
Cet élément de communication est une dimension importante. C’est pourquoi nous aborderons dans cet article les thèmes suivant :
Lire la suite de cet article »
Complet
Twitter
