BT

Êtes-vous prêts pour InfoQ 3.0? Testez le nouveau design et dites-nous ce que vous en pensez!

Utiliser un langage fonctionnel pour le Domain-Driven Design

| par Jan Stenberg Suivre 39 Abonnés , traduit par Christophe Fargeix Suivre 0 Abonnés le 13 mai 2014. Durée de lecture estimée: 2 minutes |

Quand on utilise un langage fonctionnel pour le domain-driven design (DDD), le code peut s'avérer suffisamment simple à utiliser pour pouvoir discuter des modèles avec des experts, a déclaré Scott Wlaschin lors d'un récent meeting du Functional Londoners Group durant lequel il a été question de modélisation de domaine avec la programmation fonctionnelle pour des applications réelles en utilisant F#.

Scott, en tant qu'architecte .NET et auteur de Understanding Functional Programming, admet que la programmation fonctionnelle peut être effrayante pour un développeur orienté objet à cause de tous les termes étranges à la mode comme Functor, Applicative, Monads, ...etc. Mais il ajoute qu'ils ne représentent en réalité que des termes inconnus. A l'inverse, selon Scott, c'est la programmation orientée objet qui est effrayante avec tous ses concepts, comme par exemple le polymorphisme, la généricité, l'héritage, la covariance, etc. Il pense que la programmation fonctionnelle est effectivement plus simple car il y a moins de concepts à assimiler, ce qu'il met en avant durant sa présentation en n'utilisant aucun de ces concepts.

D'après l'expérience de Scott, de nombreux développeurs estiment que la programmation fonctionnelle est utile pour résoudre des problèmes des domaines scientifiques et mathématiques, mais ne convient pas et est trop compliquée pour des applications ordinaires ; mais il pense que le F# est vraiment bon pour les choses ennuyeuses comme, les applications métiers, le développement d'applications de BLOB (Binary Large OBject) ; il est très concis, il est très commode pour éviter le passe-partout et il contient un système de types qui assure l'exactitude.

Quand on compare F# à C# pour le domain-driven development, en regardant des exemples de code au niveau des objets et des entités, Scott soutient que le F# donne souvent un code plus simple, tellement simple que le code réel peut parfois être utilisé lors de l'examen du modèle avec un expert du domaine au lieu d'utiliser des diagrammes UML ou d'autres modèles.

En expliquant le système de types de F#, Scott démontre comment les types, en plus d'être des annotations pour la vérification de type, peuvent également devenir des outils de modélisation et être utilisés pour représenter un design. Depuis que le compilateur vérifie les types, le système de type peut alors être considéré comme un test unitaire pour le temps de compilation.

un bon système de type statique, c'est comme avoir des tests unitaires de temps de compilation.

Scott conclut en affirmant que le F# représente un faible risque et un choix sûr pour le développement des fonctions primaires, son principal argument étant qu'il est recommandé par Microsoft.

Evaluer cet article

Pertinence
Style

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter
BT