Bonjour,
@ben53 quand on fais une application on doit rendre un service donné, on doit donc faire du code pour faire différentes opérations. Il existe plusieurs manière de le faire : on peux choisir de ne représenter que les données (on parle alors de data classes) et faire les traitements dans des services stateless ou, on peux faire des objets représentant le métier qui seront chargés de faire les opérations.
Par exemple, si on doit manipuler un numéro de téléphone on peux choisir de transporter uniquement une chaîne de caractères, nos services doivent donc pouvoir traiter un numéro de téléphone ou un dictionnaire Klingon. Ou alors on peux avoir un objet représentant ce numéro de téléphone qui fera le contrôle et le formatage de la donnée. En plus de nous donner une indication fiable et importante sur le type de donnée (c'est un numéro de téléphone, pas un prénom) on est aussi certains de manipuler des données saines. Maintenant, sur ce numéro de téléphone on peux avoir besoin d'ajouter l'indicateur du pays (une opération métier nécessaire dans l'application) et bien la logique pour faire cette opération peut être codée directement dans notre objet téléphone.
Dans le cas du numéro de téléphone, dans cet exemple, seules les valeurs portées sont importantes, si on change ces données on manipule alors un autre numéro de téléphone : en DDD on appel ce type d'objets des value objects. Dans la boite à outils du DDD on va trouver d'autres manières de modéliser le métier (Aggregates, Entities, Domain Events, ...) mais ça, c'est une autre (très longue) histoire
. Si ces sujets t'intérésent je te conseil de te renseigner un peu (par exemple en lisant Domain Driven Design Distilled de Vaughn Vernon) puis d'aller participer à des groupes de discussion sur le sujet pour en apprendre un peu plus.
1 |
0 |