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 VIEW
et PROCEDURE
sont. 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.