Parlons de DDD en php

DDD est l'abréviation de « Domain Driven Design », qui est souvent traduit par Domain Driven Design en chinois. Aujourd'hui, nous allons présenter DDD en php. Vous pouvez vous y référer si nécessaire.

Qu'est-ce que DDD (tout d'abord, qu'est-ce que ce n'est pas)

DDD ​​​​est l'abréviation de Domain Driven Design, qui est souvent traduit par domain-driven design en chinois. Avant de comprendre ce qu’est DDD, discutons d’abord de ce qu’il n’est pas.

• DDD ​​​​n'est pas un framework logiciel. Cependant, il existe des frameworks basés sur les idées DDD, comme Axon, qui est un framework logiciel de microservices implémenté en Java avec DDD comme idée directrice.

• DDD ​​​​n'est pas un modèle de conception de logiciel. Ce n'est pas un modèle de conception comme une usine ou un singleton. Cependant, des modèles de conception tels que Repository sont proposés dans la réflexion DDD.

• DDD ​​​​n'est pas un modèle d'architecture système. Ce n'est pas un modèle architectural comme MVC. Cependant, les idées DDD ont proposé des modèles architecturaux tels que la source d'événements (Event Sourcing) et l'isolation en lecture-écriture (Command Query Responsibility Segregation).

Alors, qu'est-ce que DDD exactement ?

Un logiciel est un outil créé pour servir les humains et améliorer la productivité humaine. Chaque logiciel sert un domaine spécifique. Par exemple, un CRM est un outil qui se concentre sur la gestion des données clients et aide les commerçants à rester en contact avec les clients.

L'essence du logiciel est le code exécuté dans l'ordinateur. Comment mapper plus précisément le code abstrait aux domaines de préoccupation humaine est un sujet que les développeurs de logiciels ont exploré, qu'il s'agisse de programmation fonctionnelle (FP) ou orientée objet. La programmation (POO) consiste à aider les développeurs à développer des modèles logiciels plus pertinents pour le domaine.

Dans les méthodes traditionnelles de développement de logiciels, nous rencontrons souvent une série de problèmes techniques et non techniques qui affectent la qualité des logiciels :

• Les développeurs sont passionnés par la technologie, mais manquent de conception et de réflexion commerciale. Les développeurs travaillent à huis clos sans bien comprendre les besoins de l'entreprise. Même si les fonctions sont lancées, personne ne s'en soucie.

• Saisie de code au lieu de saisie commerciale. Le personnel technique a un goût particulier pour la mise en œuvre de la technologie, et il existe une situation où il n'est pas nécessaire d'utiliser un couteau de taureau pour tuer un poulet.

• Trop d'accent mis sur la base de données. Un développement centré sur la conception de bases de données plutôt que sur le business entraîne souvent l'incapacité du logiciel à s'adapter à une logique métier en constante évolution.

DDD ​​​​est une idée de conception qui part du domaine (métier) et vise à résoudre la complexité de la modélisation logicielle. On peut également la comprendre comme une méthodologie de modélisation. La philosophie de conception de

DDD ​​est divisée en deux parties : stratégique et tactique.

Nous pouvons comprendre la conception stratégique comme une conception au niveau macro. Son objectif comprend l'analyse de la complexité de l'entreprise, la division du périmètre de l'entreprise, l'orientation de la méthode d'intégration commerciale, etc. Nous pouvons comprendre la conception tactique comme une conception au niveau micro (niveau code), qui nous fournit une série d'outils pour mettre en œuvre la logique métier.

Conception stratégique

Langage universel (langage omniprésent)

Le langage est l'outil de base de la communication humaine. Cependant, les développeurs sont habitués à utiliser des termes techniques et des experts de domaine (les experts de domaine font généralement référence ici à des experts compétents en affaires, tels que). (comme les utilisateurs et les clients), etc.) ne se soucient pas de la terminologie technique, provoquant ainsi d'inévitables problèmes de communication. Une fois que des problèmes de communication surviennent, il sera difficile pour le logiciel développé de résoudre les véritables problèmes des experts du domaine.

Le langage universel est la pierre angulaire de la pensée DDD. Il s'agit d'un langage de communication que les développeurs et les experts du domaine créent conjointement, un langage de communication universel qui est populaire dans l'équipe. Les membres de l'équipe peuvent utiliser le langage universel pour communiquer sans barrières.

Cela oblige les développeurs à abandonner le jargon technique, à travailler avec des experts du domaine, à se concentrer sur les problèmes commerciaux tels que les experts du domaine, à creuser et à peaufiner conjointement la terminologie de l'entreprise et à créer un langage commun.

Le langage universel peut souvent être directement appliqué au code. Il peut être directement écrit sous forme de classe ou de méthode d'une classe.

Par exemple, lors du développement d'un panier, au lieu d'utiliser des termes techniques :

• Cart::create() : Créez un panier.

• Cart::updateStatus() : Mettez à jour l'état du panier.

• Cart::remove() : Supprimez le panier.

Autant utiliser un langage commun et plus proche du business :

• Cart::init() : Créer un panier.

• Cart::addItemToCart() : ajoutez des articles.

• Cart::removeItemFromCart() : Supprimez l'article.

• Cart::empty() : videz le panier.

Lors de l'utilisation de cette dernière, les développeurs n'ont pas besoin d'expliquer la signification de chaque méthode de classe, et les experts du domaine peuvent directement comprendre le but de chaque méthode de classe. Les développeurs peuvent même s'asseoir avec des experts du domaine et travailler avec du code pour affiner les processus métier.

Contexte limité

Après avoir réalisé la liberté linguistique universelle, nous devons utiliser un contexte limité pour spécifier les limites d'utilisation de chaque ensemble de langages universels. Le contexte limité est la frontière entre la sémantique et le contexte. Chaque élément a sa propre signification spécifique, chaque concept est unique dans un contexte limité et aucune polysémie n'est autorisée.

Nous pouvons expliquer le contexte délimité avec un exemple simple. Par exemple, dans le contexte délimité d'un panier d'achat, nous pouvons utiliser le mot Utilisateur pour représenter le client qui a acheté le produit. Dans un système d'enregistrement, nous pouvons utiliser le mot Utilisateur pour désigner un compte avec un nom d'utilisateur et un mot de passe. Bien que les mots soient les mêmes, ils ont des significations différentes dans des contextes délimités différents.

Nous utilisons un contexte limité et un langage universel pour diviser l'entreprise au niveau linguistique. Le contexte délimité donne un concept clair à chaque élément du domaine, de sorte que les développeurs ne seront pas tentés de flasher plusieurs concepts qui prennent en charge un élément dans leur esprit et éviteront d'écrire du code "grosse boule de boue".

Sous-domaine

Si le contexte délimité consiste à diviser l'entreprise au niveau linguistique, alors le sous-domaine consiste à diviser la valeur commerciale de l'entreprise. Chaque entreprise a son propre objectif. Même s'il s'agit de plates-formes de commerce électronique qui se ressemblent, Taobao est un modèle de plate-forme ouverte et JD.com est un modèle d'intégration de chaîne de valeur. Une différence évidente est que Taobao utilise une logistique tierce. JD.com construit son propre système logistique.

Alors en tant que développeur, pourquoi devriez-vous vous soucier d'un modèle économique qui semble n'avoir rien à voir avec vous ? Au contraire, ce n’est que lorsque nous comprenons la structure d’une entreprise que nous pouvons développer un système avec des priorités claires pour soutenir le développement rapide d’une entreprise.

Le sous-domaine est un tel outil qui nous aide à établir des priorités.

Il existe trois types de sous-domaines :

• Domaine principal : il s'agit de la zone du système qui nécessite le plus grand investissement et qui représente la compétitivité de base de l'ensemble de l'entreprise. Nous devons consacrer beaucoup de ressources et de ressources pour peaufiner le domaine de base, qui est lié à la survie de l'entreprise. Par exemple, le système logistique auto-construit de JD.com.

• Domaine support : Ce domaine n'est pas le cœur de métier d'une entreprise, mais le domaine cœur en est indissociable. Il peut être mis en œuvre à l'aide de solutions de personnalisation d'externalisation. Par exemple, le contexte d'authentification et le contexte d'autorisation.

• Domaine générique : s'il existe une solution mature, le domaine générique peut acheter une solution prête à l'emploi. Sinon, vous pouvez également recourir à l'externalisation. Par exemple, pour Taobao, la logistique est son domaine général.

Il existe différentes opinions sur la relation entre le contexte délimité et les sous-domaines. Certains experts préconisent le 1:1, tandis que d'autres préconisent le 1:N. Personnellement, je prône le 1:1, car je suis profondément influencé par l'auteur du livre Implementing Domain-Driven Design.

Context Mapping

Dans un système immense, il doit y avoir certaines dépendances entre les contextes délimités. Comment mapper les concepts d’un contexte à un autre ? Nous utilisons la cartographie contextuelle.

Voici plusieurs types de relations de cartographie du contexte :

• Partenariat

• Noyau partagé

• Développement client-fournisseur

• Conformiste

• Anticor Couche de rupture

• Service hôte ouvert

• Langue publiée

• SeparateWay

• Big Ball of Mud

Les concepts ci-dessus sont relativement abstraits, et parfois il peut y avoir de multiples relations entre deux contextes délimités.

Ci-dessus sont plusieurs concepts fondamentaux de la conception stratégique DDD.

Conception tactique

Comment modéliser des concepts dans des contextes délimités, nous utiliserons la conception tactique fournie par DDD.

Entité

Tout d'abord, nous parlons d'entités.

Les entités sont des modèles d'éléments indépendants dans le domaine. Chaque entité possède un identifiant unique, tel que l'ID, l'UUID, le nom d'utilisateur, etc. Dans la plupart des cas, une entité est mutable et son état change avec le temps. Cependant, une entité ne doit pas nécessairement être mutable.

La plus grande caractéristique d'une entité est son individualité et son caractère unique. Par exemple, dans le cadre d'un simple panier, la commande est une entité, l'identifiant est son identifiant, et son statut peut changer entre passée, confirmée et remboursée.

Value Object

Value Object est un modèle utilisé pour décrire, quantifier ou mesurer des entités sur le terrain. Contrairement aux entités, les objets de valeur n'ont pas d'identifiants uniques et deux objets de valeur équivalents sont interchangeables. Les objets de valeur sont immuables. Une fois créés, les propriétés d'un objet de valeur sont finalisées et ne peuvent pas être modifiées.

La façon la plus directe de comprendre les objets de valeur est d'imaginer les billets de banque dans notre vie réelle, les dix yuans en RMB de A et les dix yuans en RMB de B peuvent être échangés de manière égale.

Dans le contexte du panier ci-dessus, le montant (Argent) est un objet de valeur, et le montant est composé de la devise et du montant :

class Money {
  public $currency;
  public $amount;

  function __construct($currency, $amount) {
    $this->currency = $currency;
    $this->amount = $amount;
  }  
}

L'utilisation d'objets de valeur pour la modélisation peut nous aider à utiliser le code pour créer plus précisément un modèle de domaine.

Agrégation

Qu'est-ce que l'agrégation ? L'agrégation est une division plus raffinée des domaines d'activité en contexte, et chaque agrégation garantit sa propre cohérence commerciale.

Alors, qu’est-ce que l’immuabilité d’une entreprise ? L'invariance métier représente une règle métier qui ne peut être violée dans le domaine métier et sa cohérence doit être garantie. Par exemple, lors du remboursement d’une commande, le montant du remboursement ne peut excéder le montant payé.

Les composants d'une agrégation sont des entités et des objets de valeur, et parfois uniquement des entités. Afin de protéger la cohérence commerciale de l'agrégat, chaque agrégat ne peut être exploité que par l'intermédiaire d'une certaine entité, appelée racine de l'agrégat.

Événement de domaine

Un événement de domaine est un événement analysé à travers un langage commun, contrairement aux événements de transaction courants, il est étroitement lié à l'entreprise, son nom contient donc souvent des noms professionnels et ne doit pas être lié à la base de données. Par exemple, lors de l'ajout de produits au panier, l'événement de domaine correspondant doit être ProductAddedToCart et non CartUpdated.

Résumé

DDD ​​​​fournit également des conceptions tactiques telles que le service d'application et le service de domaine. DDD propose également des modèles architecturaux tels que le sourcing d'événements et l'hexagone mentionnés ici. Nous ne les présenterons pas un par un.

Le cœur de DDD est de construire un modèle de logiciel d'un point de vue commercial. Son objectif est de créer un code plus proche de l'entreprise et de clarifier les processus métier à partir du code de manière plus intuitive. Cependant, réaliser DDD ne se fait pas en un jour. Cela nécessite une pratique et un perfectionnement continus.

Apprentissage recommandé : Tutoriel vidéo php

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!