La conception pilotée par domaine est une méthodologie et une prescription de processus pour le développement de systèmes complexes dont l'objectif est de mapper les activités, les tâches, les événements et les données d'un domaine problématique dans les artefacts technologiques d'un domaine de solution.
La conception pilotée par domaine met l'accent sur la compréhension du domaine problématique afin de créer un modèle abstrait du domaine problématique qui peut ensuite être implémenté dans un ensemble particulier de technologies. La conception pilotée par le domaine en tant que méthodologie fournit des directives sur la façon dont ce développement de modèle et le développement technologique peuvent aboutir à un système qui répond aux besoins des personnes qui l'utilisent tout en étant robuste face aux changements dans le domaine problématique.
Le côté processus de la conception pilotée par le domaine implique la collaboration entre les experts du domaine, les personnes qui connaissent le domaine problématique et les experts en conception / architecture, les personnes qui connaissent le domaine de la solution. L'idée est d'avoir un modèle partagé avec un langage partagé de sorte qu'en tant que personnes de ces deux domaines différents avec leurs deux perspectives différentes discutent de la solution, elles discutent réellement d'une base de connaissances partagée avec des concepts partagés.
L'absence d'une compréhension commune du domaine problématique entre les personnes qui ont besoin d'un système particulier et les personnes qui conçoivent et mettent en œuvre le système semble être un obstacle majeur à la réussite des projets. La conception pilotée par le domaine est une méthodologie pour remédier à cet obstacle.
C'est plus que d'avoir un modèle objet. L'accent est vraiment mis sur la communication partagée et l'amélioration de la collaboration afin que les besoins réels dans le domaine problématique puissent être découverts et une solution appropriée créée pour répondre à ces besoins.
Conception basée sur le domaine: le bien et le défi fournit un bref aperçu de ce commentaire:
DDD permet de découvrir l'architecture de haut niveau et de renseigner sur la mécanique et la dynamique du domaine que le logiciel doit répliquer. Concrètement, cela signifie qu'une analyse DDD bien réalisée minimise les malentendus entre les experts du domaine et les architectes logiciels, et réduit le nombre ultérieur de demandes de changement coûteuses. En divisant la complexité du domaine dans des contextes plus petits, DDD évite de forcer les architectes de projet à concevoir un modèle d'objet gonflé, ce qui représente une perte de temps considérable pour l'élaboration des détails d'implémentation - en partie parce que le nombre d'entités à traiter dépasse souvent le taille des tableaux blancs de la salle de conférence.
Consultez également cet article Conception pilotée par domaine pour l'architecture de services qui fournit un court exemple. L'article fournit la description miniature suivante de la conception pilotée par domaine.
La conception pilotée par le domaine préconise une modélisation basée sur la réalité de l'entreprise et pertinente pour nos cas d'utilisation. À mesure qu'il vieillit et que le niveau de battage médiatique diminue, beaucoup d'entre nous oublient que l'approche DDD aide vraiment à comprendre le problème à résoudre et à concevoir un logiciel pour une compréhension commune de la solution. Lors de la création d'applications, DDD parle des problèmes en tant que domaines et sous-domaines. Il décrit les étapes / domaines de problèmes indépendants comme des contextes limités, met l'accent sur un langage commun pour parler de ces problèmes et ajoute de nombreux concepts techniques, tels que des entités, des objets de valeur et des règles racine agrégées pour prendre en charge la mise en œuvre.
Martin Fowler a écrit un certain nombre d'articles dans lesquels la conception pilotée par domaine en tant que méthodologie est mentionnée. Par exemple, cet article, BoundedContext , fournit une vue d'ensemble du concept de contexte borné de Domain Driven Development.
Dans ces jours plus jeunes, il nous a été conseillé de construire un modèle unifié de l'ensemble de l'entreprise, mais DDD reconnaît que nous avons appris que "l'unification totale du modèle de domaine pour un grand système ne sera pas réalisable ou rentable" 1 . Au lieu de cela, DDD divise un grand système en contextes délimités, chacun pouvant avoir un modèle unifié - essentiellement un moyen de structurer MultipleCanonicalModels.