La conception pilotée par le domaine est-elle un modèle anti-SQL?

Je plonge dans le DDD (Domain Driven Design) et même si j'y vais plus profondément, il y a des choses que je ne comprends pas. Si je comprends bien, l’un des principaux objectifs est de séparer la logique de domaine (logique d’entreprise) de l’infrastructure (base de données, système de fichiers, etc.).

Ce que je me demande, c'est ce qui se passe lorsque j'ai des requêtes très complexes comme une requête de calcul de ressources matérielles. Dans ce type de requête, vous travaillez avec des opérations sur des ensembles lourds, le genre de choses pour lesquelles SQL a été conçu. Effectuer ces calculs à l'intérieur de la couche de domaine et travailler avec de nombreux ensembles, c'est comme abandonner la technologie SQL.

Ces calculs dans l'infrastructure ne peuvent pas se produire non plus, car le modèle DDD permet de modifier l'infrastructure sans changer la couche de domaine et sachant que MongoDB ne dispose pas des mêmes fonctionnalités, par exemple SQL Server, cela ne peut pas se produire.

Est-ce un piège du modèle DDD?

De nos jours, il est probable que les lectures (requêtes) soient traitées différemment des écritures (commandes). Dans un système avec une requête compliquée, il est peu probable que la requête elle-même passe par le modèle de domaine (qui est principalement responsable du maintien de la cohérence des écritures ).

Vous avez absolument raison de dire que nous devrions rendre à SQL ce qui est SQL. Nous allons donc concevoir un modèle de données optimisé autour des lectures, et une requête de ce modèle de données utilise généralement un chemin de code n'incluant pas le modèle de domaine (à l'exception peut-être d'une validation d'entrée - garantissant que les paramètres de la requête sont raisonnables).

Si je comprends bien, l’un des principaux objectifs est de séparer la logique de domaine (logique d’entreprise) de l’infrastructure (base de données, système de fichiers, etc.).

C’est là le fondement du malentendu: le but de DDD n’est pas de séparer les choses le long d’une ligne dure comme "ceci est dans le serveur SQL, donc ne doit pas être BL", le but de DDD est de séparer les domaines et de créer des barrières entre ceux qui permettent aux éléments internes d’un domaine d’être complètement séparés des éléments internes d’un autre domaine et de définir des éléments externes partagés entre eux.

Ne pensez pas que "être en SQL" est la barrière BL / DL - ce n'est pas ça. Au lieu de cela, pensez à "c'est la fin du domaine interne" en tant que barrière.

Chaque domaine doit avoir des API externes lui permettant de fonctionner avec tous les autres domaines: dans le cas de la couche de stockage de données , il doit comporter des actions de lecture / écriture (CRUD) pour les objets de données qu'il stocke. Cela signifie que SQL lui-même n'est pas vraiment la barrière, les composants VIEWet PROCEDUREsont. Vous ne devriez jamais lire directement dans le tableau: c’est le détail de l’implémentation que DDD nous dit qu’en tant que consommateur externe, nous ne devrions pas nous inquiéter.

Considérez votre exemple:

Ce que je me demande, c'est ce qui se passe lorsque j'ai des requêtes très complexes comme une requête de calcul de ressources matérielles. Dans ce type de requête, vous travaillez avec des opérations sur des ensembles lourds, le genre de choses pour lesquelles SQL a été conçu.

C’est exactement ce qui devrait être dans SQL alors, et ce n’est pas une violation de DDD. C'est ce pour quoi nous avons fait DDD . Avec ce calcul en SQL, cela fait partie de la BL / DL. Ce que vous feriez, c’est d’utiliser une vue / procédure stockée / what-have-you distincte et de maintenir la logique métier séparée de la couche de données, car c’est votre API externe. En fait, votre couche de données doit être une autre couche de domaine DDD, dans laquelle votre couche de données possède ses propres abstractions pour fonctionner avec les autres couches de domaine.

Ces calculs dans l'infrastructure ne peuvent pas se produire non plus, car le modèle DDD permet de modifier l'infrastructure sans changer la couche de domaine et sachant que MongoDB ne dispose pas des mêmes fonctionnalités, par exemple SQL Server, cela ne peut pas se produire.

C'est un autre malentendu: il est dit que les détails de l'implémentation en interne peuvent changer sans changer les autres couches de domaine. Il ne dit pas que vous pouvez simplement remplacer tout un élément d'infrastructure.

Encore une fois, rappelez-vous, DDD consiste à masquer les éléments internes avec des API externes bien définies. La position de ces API est une question totalement différente, et DDD ne le définit pas. Il définit simplement que ces API existent et ne devraient jamais changer .

DDD n'est pas configuré pour vous permettre de remplacer ad-hoc MSSQL par MongoDB: il s'agit de deux composants d'infrastructure totalement différents.

Utilisons plutôt une analogie pour définir ce que DDD définit: les voitures à essence par rapport aux voitures électriques. Les deux véhicules ont deux méthodes complètement différentes pour créer une propulsion, mais ils ont les mêmes API: un marche / arrêt, une manette des gaz / frein et des roues pour propulser le véhicule. DDD affirme que nous devrions pouvoir remplacer le moteur (à essence ou électrique) de notre voiture. Cela ne dit pas que nous pouvons remplacer la voiture par une moto, et c'est en fait ce que MSSQL → MongoDB est.

Si vous avez déjà participé à un projet pour lequel l'organisation qui paye l'hôte de l'application décide que les licences de couche de base de données sont trop chères, vous apprécierez la facilité avec laquelle vous pouvez migrer votre stockage de base de données / données. Tout bien considéré, même si cela arrive, cela n'arrive pas souvent .

Vous pouvez obtenir le meilleur des deux mondes pour ainsi dire. Si vous considérez que l'exécution des fonctions complexes de la base de données est une optimisation, vous pouvez utiliser une interface pour injecter une autre implémentation du calcul. Le problème est que vous devez maintenir la logique à plusieurs endroits.

Déviant d'un motif architectural

Lorsque vous vous trouvez en désaccord avec la mise en œuvre d'un schéma purement ou avec des écarts dans certains domaines, vous avez une décision à prendre. Un modèle est simplement un moyen de faire des choses sur la base de modèles pour aider à organiser votre projet. À ce stade, prenez le temps d’évaluer:

• Est-ce le bon modèle? (plusieurs fois c'est le cas, mais parfois c'est juste un mauvais ajustement)
• Devrais-je dévier de cette manière?
• Jusqu'où ai-je dévié jusqu'à présent?

Vous constaterez que certains modèles d'architecture conviennent pour 80 à 90% de votre application, mais pas autant pour les bits restants. L’écart occasionnel par rapport au modèle prescrit est utile pour des raisons de performance ou de logistique.

Toutefois, si vous constatez que vos écarts cumulatifs représentent bien plus de 20% de votre architecture d’application, il s’agit probablement d’un mauvais ajustement.

Si vous choisissez de vous en tenir à l'architecture, alors rendez-vous service et indiquez où et pourquoi vous vous êtes écarté de la façon de faire prescrite. Lorsque vous avez un nouveau membre enthousiaste dans votre équipe, vous pouvez lui indiquer la documentation qui comprend les mesures de performance et les justifications. Cela réduira le risque de demandes répétées pour résoudre le "problème". Cette documentation contribuera également à dissuader les déviations généralisées.

La logique de manipulation des ensembles dans laquelle SQL est bon peut être intégrée à DDD sans problème.

Supposons par exemple que je doive connaître une valeur globale, le nombre total de produits par type. Facile à exécuter en sql, mais lent si je charge tous les produits en mémoire et les additionne tous.

J'introduis simplement un nouvel objet de domaine,

ProductInventory
{
    ProductType
    TotalCount
    DateTimeTaken
}

et une méthode sur mon référentiel

ProductRepository
{
    List<ProductInventory> TakeInventory(DateTime asOfDate) {...}
}

Bien sûr, je compte peut-être maintenant sur certaines bases de ma DB. Mais techniquement, j'ai toujours la séparation et tant que la logique est simple, je peux dire que ce n'est pas de la "logique métier"

Pour résoudre ce dilemme, l’un des moyens possibles consiste à considérer le langage SQL comme un langage d’assemblage: vous codez directement dans ce langage, mais lorsque les performances sont importantes, vous devez être en mesure de comprendre le code produit par votre langage. / C ++ / Golang / Rust et peut-être même écrire un petit fragment d'assemblage, si vous ne pouvez pas modifier le code dans votre langage évolué pour produire le code machine souhaité.

De même, dans le domaine des bases de données et du langage SQL, diverses bibliothèques SQL (dont certaines sont ORM ), telles que SQLAlchemy et Django ORM pour Python, LINQ pour .NET, fournissent des abstractions de niveau supérieur tout en utilisant le code SQL généré dans la mesure du possible pour améliorer les performances. Elles fournissent également une certaine portabilité quant à la base de données utilisée, avec éventuellement des performances différentes, par exemple sur Postgres et MySQL, en raison de certaines opérations utilisant un code SQL plus optimal spécifique à la base de données.

Et comme pour les langages de haut niveau, il est essentiel de comprendre le fonctionnement de SQL, même s'il ne s'agit que de réorganiser les requêtes effectuées avec les bibliothèques SQL mentionnées ci-dessus, pour pouvoir atteindre l'efficacité souhaitée.

PS Je préférerais en faire un commentaire mais je n’ai pas une réputation suffisante pour cela.

Comme d'habitude, c'est l'une de ces choses qui dépend d'un certain nombre de facteurs. Il est vrai que vous pouvez faire beaucoup de choses avec SQL. Son utilisation présente également des difficultés et certaines limitations pratiques des bases de données relationnelles.

Comme Jared Goguen le note dans les commentaires, SQL peut être très difficile à tester et à vérifier. Les principaux facteurs qui ont conduit à cela sont le fait qu’il ne peut pas (en général) être décomposé en composants. En pratique, une requête complexe doit être considérée dans son intégralité. Un autre facteur de complication est que le comportement et l'exactitude du code SQL dépendent fortement de la structure et du contenu de vos données. Cela signifie que tester tous les scénarios possibles (ou même déterminer ce qu'ils sont) est souvent irréalisable ou impossible. Le refactoring de SQL et la modification de la structure de la base de données sont également problématiques.

L'autre facteur important qui a conduit à l'abandon de SQL est que les bases de données relationnelles ont tendance à évoluer uniquement verticalement. Par exemple, lorsque vous générez des calculs complexes en SQL à exécuter dans SQL Server, ils s'exécutent sur la base de données. Cela signifie que tout ce travail utilise des ressources sur la base de données. Plus vous en ferez avec SQL, plus votre base de données aura besoin de ressources en mémoire et en CPU. C’est souvent moins efficace de faire cela sur d’autres systèmes, mais il n’ya pas de limite pratique au nombre de machines supplémentaires que vous pouvez ajouter à une telle solution. Cette approche est moins coûteuse et plus tolérante aux pannes que la construction d’un serveur de base de données monstre.

Ces problèmes peuvent ou non s’appliquer au problème à résoudre. Si vous êtes capable de résoudre votre problème avec les ressources de base de données disponibles, peut-être que SQL convient à votre problème. Vous devez toutefois envisager la croissance. Tout va bien aujourd'hui, mais dans quelques années, l'ajout de ressources supplémentaires risque de poser problème.

Est-ce un piège du modèle DDD?

Permettez-moi d’abord de dissiper quelques idées fausses.

DDD n'est pas un motif. Et cela ne prescrit pas vraiment de modèles.

La préface du livre DDD d'Eric Evan se lit comme suit :

Les principaux concepteurs de logiciels considèrent la modélisation et la conception de domaines comme des sujets critiques depuis au moins 20 ans. Pourtant, étonnamment, peu de choses ont été écrites sur ce qui doit être fait ou comment le faire. Bien qu’elle n’ait jamais été clairement formulée, une philosophie est apparue comme un courant sous-jacent dans la communauté d’objets, une philosophie que j’appelle la conception pilotée par domaine.

[...]

Une caractéristique commune aux succès est un modèle de domaine riche qui a évolué à travers des itérations de conception et est devenu une partie intégrante de la structure du projet.

Ce livre fournit un cadre pour prendre des décisions de conception et un vocabulaire technique pour discuter de la conception de domaines. C'est une synthèse des meilleures pratiques largement acceptées ainsi que de mes propres idées et expériences.

C'est donc une façon d'aborder le développement de logiciels et la modélisation de domaine, ainsi que du vocabulaire technique prenant en charge ces activités (un vocabulaire comprenant divers concepts et schémas). Ce n'est pas quelque chose de complètement nouveau.

Une autre chose à garder à l'esprit est qu'un modèle de domaine n'est pas sa mise en œuvre OO qui peut être trouvée dans votre système - c'est juste une façon de l'exprimer, ou d'en exprimer une partie. Un modèle de domaine est la façon dont vous envisagez le problème que vous essayez de résoudre avec le logiciel. C'est comment vous comprenez et percevez les choses, comment vous en parlez. C'est conceptuel . Mais pas dans un sens vague. C'est profond et raffiné, et c'est le résultat d'un travail acharné et de la collecte de connaissances. Il est ensuite affiné et a probablement évolué au fil du temps et implique des considérations de mise en œuvre (dont certaines peuvent limiter le modèle). Il devrait être partagé par tous les membres de l'équipe (et experts de domaine impliqués), et cela devrait guider la manière dont vous implémentez le système, de sorte que le système le reflète étroitement.

Rien à ce sujet n'est intrinsèquement pro ou anti-SQL, bien que les développeurs OO soient peut-être généralement mieux en mesure d'exprimer le modèle dans des langages OO, et que l'expression de nombreux concepts de domaine est mieux prise en charge par OOP. Mais parfois, certaines parties du modèle doivent être exprimées dans un paradigme différent.

Ce que je me demande, c'est ce qui se passe lorsque j'ai des requêtes très complexes [...]?

De manière générale, il existe deux scénarios.

Dans le premier cas, certains aspects d'un domaine nécessitent en réalité une requête complexe, et cet aspect est peut-être mieux exprimé dans le paradigme SQL / relationnel - utilisez donc l'outil approprié pour le travail. Reflétez ces aspects dans votre pensée de domaine et le langage utilisé dans la communication de concepts. Si le domaine est complexe, il s'agit peut-être d'une partie d'un sous-domaine avec son propre contexte lié.

L'autre scénario est que le besoin perçu d'exprimer quelque chose en SQL est le résultat d'une pensée contrainte. Si une personne ou une équipe a toujours eu une pensée orientée base de données, il peut être difficile pour elles, juste à cause de l'inertie, de voir une manière différente d'aborder les choses. Cela devient un problème lorsque l'ancienne méthode ne répond pas aux nouveaux besoins et nécessite une réflexion originale. DDD, en tant qu'approche de la conception, consiste en partie à trouver des moyens de sortir de cette boîte en rassemblant et en distillant les connaissances sur le domaine. Mais tout le monde semble ignorer cette partie du livre et se concentre sur le vocabulaire technique et les modèles énumérés.

Sequel est devenu populaire lorsque la mémoire coûtait cher, car le modèle de données relationnel offrait la possibilité de normaliser vos données et de les stocker efficacement dans le système de fichiers.

Maintenant, la mémoire est relativement peu coûteuse, nous pouvons donc ignorer la normalisation et stocker dans le format que nous utilisons ou même dupliquer beaucoup de mêmes données pour des raisons de rapidité.

Considérez la base de données comme un simple périphérique IO , auquel il incombe de stocker des données dans le système de fichiers - oui, je sais que c'est difficile à imaginer, car nous avons écrit de nombreuses applications avec une logique métier importante écrite dans des requêtes SQL - mais essayez simplement d'imaginer que SQL Server est juste une autre imprimante.

Souhaitez-vous incorporer le générateur de PDF dans le pilote d'imprimante ou ajouter un déclencheur qui imprimera une page de journal pour chaque commande client imprimée sur notre imprimante?

Je suppose que la réponse sera non, car nous ne voulons pas que notre application soit couplée au type de périphérique spécifique (sans même parler de l'efficacité d'une telle idée)

Dans les années 70-90, la base de données SQL était efficace, maintenant? - Vous n'êtes pas sûr que, dans certains cas, une requête de données asynchrone renvoie les données requises plus rapidement que plusieurs jointures dans une requête SQL.

Le langage SQL n'était pas conçu pour les requêtes complexes, mais pour le stockage efficace des données, puis pour fournir une interface / un langage permettant d'interroger les données stockées.

Je dirais que construire votre application autour d'un modèle de données relationnel avec des requêtes complexes constitue un abus du moteur de base de données. Bien entendu, les fournisseurs de moteur de base de données sont satisfaits lorsque vous associez étroitement votre entreprise à leur produit. Ils seront plus qu'heureux de fournir davantage de fonctionnalités qui rendront ce lien plus fort.