Comme chacun le sait, Microsoft Dynamics NAV ("NAV") est une solution ouverte dont chaque partenaire peut "librement" modifier l'ensemble des objets applicatifs en utilisant l'environnement de développement intégré ("IDE" pour les intimes).
Mais "librement" ne veut pas dire "n'importe comment" : au delà des aspects liés aux coûts de développement (ET de maintenance), il faut bien comprendre que NAV a été conçu et structuré à l'aide de "pattern", c'est à dire de motifs récurrents.
Ces patterns ou motifs sont donc des solutions éprouvées répondantes à des besoins précis, largement réutilisées et réutilisables. Ils sont la garantie de l'homogénéité du produit dans tous les domaines : ergonomie, utilisabilité, processus, paramétrage, etc. Ils permettent évidement de diminuer les efforts de développement tout en réduisant les risques de dysfonctionnement.
Ces pattern ne sont pas explicitement documentés mais l’appréhension et la compréhension de ces derniers est capitale pour tout consultant/concepteur qui se respecte. C'est d'autant plus vrai qu'est né en 2012 un groupe de travail sur ces patterns, à l'initiative de Microsoft.
Le contenu de ce groupe de travail est accessible sur la page éponyme "Design Patterns" : il regroupe les différents patterns publiés à ce jour. J'ai personnellement contribué en rédigeant le "Document Pattern" qui explique comment est structuré un document dans NAV (devis, commande, etc.).
Alors vous me direz, pourquoi tous ces patterns ne sont pas officiellement documentés...? C'est une autre histoire...!
ps : pour information, il faut savoir que les concepteurs de Navision à l'époque ont largement utilisé U.M.L., la preuve en images avec une publication de Pavel Hruby datant de 1998 !
