DSL - langage spécifique à un domaine. Commençons par ce qu'est un domaine - un domaine est une zone définie, une étendue. Ce domaine peut être l'apparence d'un site web, et vous avez pour cela CSS, et le second domaine peut être la structure d'un site web, et ici vous avez HTML.
Mais le domaine peut aussi être une application de l'entreprise X. Et dans le cadre de ce domaine, un langage peut être créé. Un langage ne signifie pas qu'il s'agit d'une chose à part entière avec sa propre grammaire, sa propre syntaxe, son propre compilateur ou son propre moteur d'exécution. Le DSL peut n'être qu'une liste d'outils permettant de résoudre les problèmes du domaine.
Considérons la POO et son modèle pour représenter les objets du domaine par des classes et les méthodes comme les comportements de ces objets. Si nous créons une telle structure et donnons à ces objets des comportements, nous pouvons alors écrire un code en utilisant ces concepts. Considérons cet exemple de pseudo-code :
cookie = async getCookie(cookieId)
user = async getUser(userId)
result async user.buy(cookie)
if (result.isError()) {
error.showAlert("User has not enough money")
} else {
confirmation.showSuccess("Cookie was bought")
}
Quelle est la part de la GPL (langage à usage général) et quelle est la part de la terminologie et des outils spécifiques au domaine. Il s'agit d'un mélange des deux, mais toutes les commandes sont ici spécifiques au domaine. Cela dit, nous pouvons dire que ce qui précède est écrit dans un DSL dont le domaine est une application x.
En poursuivant cet exemple, je peux créer des outils encore plus abstraits, et réaliser le flux de contrôle à l'aide de ces outils, considérer (c'est plus FP, mais j'espère que vous comprenez ce que je veux dire) :
waitForMany(getCookie(cookieId), getUser(userId)
.andThen([cookie, user] -> user.buy(cookie))
.andThen(showSuccess("Cookie was bought"))
.whenError(showError("User has not enough money"))
Comme vous pouvez le voir, j'ai pu abstraire beaucoup de choses et utiliser cette abstraction pour réaliser le flux de contrôle. Et tout est basé sur la GPL et fonctionne dans le cadre de la GPL.
En réalité, nous écrivons tous des DSL, toutes les abstractions spécifiques à un domaine que nous pouvons utiliser sont de ce type. Mais la plupart de ces abstractions ne sont pas des solutions complètes, c'est pourquoi nous essayons de ne pas utiliser ce mot trop souvent. Mais si vous disposez d'un ensemble d'outils, de fonctions qui abstraient votre domaine, ils forment une sorte de DSL.
Ce qui est aussi DSL, c'est beaucoup de choses, par exemple tout cadre qui fournit un ensemble de règles est DSL. Si vous voyez quelqu'un prétendre être un développeur React, alors vous savez qu'il est un développeur spécifique à un domaine, car React est exactement un DSL qui est une alternative à l'utilisation d'une plateforme web native. Si vous pouvez composer des fonctionnalités à partir d'outils existants spécifiques à un domaine, alors vous écrivez à l'aide d'un DSL. En allant plus loin dans React, désolé pour tous ceux qui ne font pas partie de ce DSL :D, vous pouvez créer un ensemble de composants, et les composer comme des blocs de construction, et hurra !, maintenant vous avez fait un DSL au dessus du DSL.
Yep a répété DSL trop souvent ici, désolé.
