Langage omniprésent - conflit entre l'exactitude et l'utilisabilité

10

Une partie essentielle de la conception pilotée par le domaine est l'utilisation cohérente d'un langage omniprésent dans le système - dans les conversations, le code, le schéma de base de données, l'interface utilisateur, les tests, etc.

Je participe à un projet dans lequel il existe déjà un langage de domaine bien établi, défini par une organisation internationale de normalisation.

Cependant, le travail que nous faisons concerne un site Web public et les termes «corrects» pour le domaine ne sont pas nécessairement la manière dont le public les utilise et les comprend généralement.

Le compromis que nous utilisons pour le moment est d'utiliser les termes «officiels» partout, sauf dans nos critères d'acceptation qui se réfèrent aux composants de l'interface utilisateur, où nous utilisons les noms informels.

Cela semble-t-il une approche raisonnable?

documentation domain-specific-languages Andy Waite
la source
Pouvez-vous fournir un exemple? Je pourrais alors donner une réponse plus détaillée. Avez-vous besoin de circonscrire ces termes ou existe-t-il des termes en collision avec des significations différentes au total? Serait-il possible de trouver un terrain d'entente entre les termes informels et la langue du domaine?
Falcon
1
Cela fait un moment que je n'ai pas lu cette partie du livre d'Evans, mais je pensais que le langage omniprésent devait être utilisé avec l'expert du domaine? Je ne m'attendrais certainement pas à ce qu'un utilisateur comprenne toute la terminologie de l'expert en domaine, je ne présenterais donc à l'utilisateur que ce que vous avez surnommé les noms informels.
Kaleb Pederson

Réponses:

7

Oui, cela semble raisonnable. Si le public visé ne comprend pas les termes de votre langue ou les interprète mal, la convivialité pour l'utilisateur final prévaut.

Un programme ou un contenu qu'un utilisateur type ne comprend pas a peu de valeur. Plus encore, si vous voulez seulement leur présenter une pointe simplifiée d'un iceberg car ils ne sont pas et ne seront jamais des experts du domaine.

Normalement, lorsque vous parlez du domaine pendant le développement, tout le monde comprend le langage car il est précis et toutes les personnes se trouvent dans le domaine. Mais si la valeur commerciale est créée par la communication de contenu à des tiers du domaine, faites-le le plus simplement possible. Utilisez des libellés et des langues les moins susceptibles d'être mal compris et utilisez-les dans l'interface utilisateur.

Conservez la langue exacte dans votre code et pour communiquer avec les personnes concernées par le domaine. Ce sont les personnes qui ont les spécifications et qui sont les principaux utilisateurs des applications, celles avec qui vous discutez des détails logiques de l'entreprise. Dans les rares cas où vous discutez vraiment de la plupart des détails logiques de l'entreprise avec des utilisateurs qui n'ont pas la moindre idée du domaine et que vous n'avez pas besoin de plonger profondément dans celui-ci, puis d'incorporer leur langue dans la langue de votre domaine, étant donné qu'ils avoir une langue commune, sans ambiguïté (ce qui n'est probablement pas le cas).

Mais assurez-vous que les développeurs frontend connaissent vos conditions informelles et leurs conditions de domaine correspondantes.

Faucon
la source
1

Je pense que la façon la plus simple de répondre à cette question serait de tracer une ligne exactement là où vous la traceriez si vous présentiez l'interface utilisateur dans une langue complètement différente.

Si vos utilisateurs finaux avaient besoin de voir les choses en sanskrit, comment combleriez-vous la différence entre l'interface utilisateur et le code (et les autres communications internes).

John Fisher
la source
Bien dit. Cela met en évidence le «problème Humpty-Dumpty»: les mots ne sont pas seulement une substitution, ils se réfèrent à des choses que les gens connaissent indépendamment des mots et de leur utilisation. Les animaux comprennent par exemple l'idée de «température». Nous sommes accrochés aux mots, quand ils ne sont que des symboles de concepts. Les concepts sont les choses importantes.