1. Quelle est la structure
D'une manière générale, l'architecture est une structure combinée, comprenant l'architecture du produit et l'architecture du système.Une bonne architecture peut rendre les produits et les systèmes mieux présentés, mieux itérés et maintenus. Une bonne architecture est développée et un bon code est refactorisé.
Nous entendons souvent des noms tels que plate-forme intermédiaire, plate-forme, système et application. Quelle est la relation entre eux auparavant ?
1) Application : C'est la plus petite granularité et elle est utilisée pour réaliser les fonctions du système d'entreprise. Par exemple, les microservices sont maintenant populaires et les applications qui implémentent un système d'entreprise incluent généralement : les applications Web et les applications de service.
2) Système : les systèmes mentionnés ici sont tous des systèmes d'entreprise. Généralement, un système d'entreprise est au moins un produit commercial complet. Tels que le système d'approvisionnement, le système d'appel d'offres, etc.
3) Plate-forme : elle est composée de plusieurs systèmes d'entreprise. Les capacités de la plate-forme sont plus riches que celles d'un seul système d'entreprise. La plate-forme fournit des capacités d'entreprise relativement complètes dans un certain domaine. Par exemple, la plate-forme d'approvisionnement est composée de systèmes commerciaux tels que l'approvisionnement et les appels d'offres. La plate-forme est une réutilisation fonctionnelle et ne prend généralement en charge qu'un seul scénario, tel qu'une plate-forme d'approvisionnement de grande entreprise, qui ne prend en charge que le scénario d'approvisionnement de grande entreprise.
4) Plate-forme intermédiaire : sur la base de la plate-forme, plusieurs scénarios sont pris en charge via des points d'extension, ce qui correspond à la réutilisation commerciale. La centrale d'approvisionnement peut prendre en charge l'approvisionnement des grandes entreprises, des petites et moyennes entreprises et des particuliers.
Chaque niveau a sa propre architecture (architecture de plate-forme, architecture de système d'entreprise, architecture d'application) et se concentre également sur différentes choses. L'architecture de la plateforme et l'architecture du système accordent plus d'attention à : la répartition des limites de responsabilité, les méthodes de déploiement et l'application des nouvelles technologies (accès au cloud, microservices, etc.). L'architecture de l'application se concentre davantage sur la superposition et la conception de l'application elle-même. Par exemple, l'architecture en couches et la conception basée sur le domaine DDD sont plus populaires maintenant , et l'architecture d'application sera au centre de cet article.
2. Répartition des responsabilités
La division des frontières du système est cruciale pour l'architecture d'entreprise.Le principe général est : la division selon les responsabilités. Lorsqu'une responsabilité ne sait pas à quel domaine elle est affectée, un domaine intermédiaire peut être affecté.
En analysant les cas d'utilisation, les modèles d'un même domaine doivent beaucoup interagir, et les modèles inter-domaines doivent rarement interagir. Si vous constatez que les modèles inter-domaines interagissent beaucoup, il est probable qu'il y ait un problème avec la répartition des responsabilités du domaine
3. Conception axée sur le domaine et ses composants de base
Introduction à la conception pilotée par domaine
Qu'est-ce que Domain Driven ? La conception pilotée par le domaine est une idée qui guide la conception et le développement du système. Elle nous oblige à prêter attention à la connaissance du domaine métier, à comprendre la connaissance du domaine et à être orienté domaine et orienté modèle. Plutôt qu'une conception orientée vers la technologie, orientée vers les données. Grâce à une communication continue avec des experts du domaine d'activité, une compréhension approfondie de la connaissance du domaine, une itération continue de la conception du système, puis la présentation d'un meilleur modèle de domaine. Un modèle de domaine valable ne doit pas apparaître immédiatement, mais doit être obtenu après une compréhension approfondie de la connaissance du domaine.
Pourquoi la conception de domaine est-elle nécessaire ? La complexité d'un système logiciel ne vient souvent pas de la mise en œuvre technique elle-même, mais de l'entreprise elle-même, des processus commerciaux complexes et de l'évolution.
Le modèle de domaine doit être compris par les experts techniques et commerciaux. Si les experts du domaine ne peuvent pas comprendre le modèle de domaine, le modèle doit être conçu de manière incorrecte. La modélisation de domaine ne consiste pas seulement à créer des entités, mais inclut également des objets de valeur, des services de domaine et des modèles de mise en œuvre. La conception et la mise en œuvre doivent être liées, et la conception et la mise en œuvre ne doivent pas être séparées. Lorsque vous voyez la conception du domaine, vous devez connaître le mode d'implémentation du système. Sinon, les implémenteurs ne comprendront pas l'intention de conception du domaine, plus l'implémentation du système s'écarte de la conception du domaine et l'intégrité des données du modèle de domaine est difficile à garantir. L'ensemble de la conception du domaine n'aura aucun sens.
Le modèle de domaine n'est pas seulement une abstraction des concepts de base du domaine, mais peut également guider le développement et la mise en œuvre de logiciels. La conception orientée objet est le paradigme de modélisation utilisé pour la plupart des modélisations de domaine.
Les composants principaux du domaine incluent les objets de domaine et la gestion du cycle de vie des objets de domaine. Les objets de domaine incluent : les entités, les objets de valeur et les services de domaine. La gestion du cycle de vie des objets du domaine comprend : la fabrique, le référentiel, l'agrégation. Les objets de domaine et la gestion du cycle de vie des objets de domaine sont les principaux actifs de la couche domaine .
1) Entité : une entité peut exister indépendamment et avoir un sens dans l'interaction commerciale, et nécessite l'existence d'un signe unique, et le signe unique a une signification commerciale réelle. Par exemple, lors d'un achat en ligne, bien que le contenu des colis envoyés soit le même, il s'agit de deux colis différents.
2) Objets de valeur : ne se soucient généralement que du contenu, ne se soucient pas de la nécessité d'un identifiant unique et utilisent l'agrégation comme attribut supplémentaire de l'entité. Par exemple, lorsqu'une personne dessine avec un pinceau, elle ne se soucie que de la couleur, de l'épaisseur et des autres caractéristiques du pinceau, pas de quel pinceau il s'agit. Bref, dans la scène, si le contenu est exactement le même, il peut être considéré comme le même objet, c'est un objet valeur, sinon c'est une entité.
3) Service de domaine : Parfois, il y aura des opérations spéciales dans le domaine, qui n'appartiennent à aucune entité ou objet de valeur. À ce stade, les services de domaine peuvent être utilisés. À l'heure actuelle, les services de domaine sont le meilleur moyen de représenter les concepts de domaine. Les paramètres et les valeurs de retour des services de domaine doivent être des modèles dans le domaine et les services doivent être sans état.
4) Agrégation : L'agrégation consiste à prendre une entité comme racine agrégée et à agréger d'autres objets de valeur comme attributs. La racine agrégée doit être la plus petite unité de modification/requête et doit être modifiée/interrogée avec la racine agrégée comme unité. L'agrégation fait généralement référence à la relation entre les entités et les objets de valeur, et l'association fait généralement référence à la relation entre les entités.
5) Usine : la principale responsabilité de l'usine est de créer des objets et de reconstruire des objets (reconstruire les données interrogées à partir du support de stockage en objets de domaine). La création d'objets complexes appartient à la couche de domaine. Elle ne doit pas nécessairement être réalisée via l'objet lui-même, mais peut être créée via la fabrique. Les usines sont généralement utilisées pour créer des types d'objets complexes qui nécessitent une généralisation, et des objets modèles simples peuvent être créés directement via des constructeurs.
6) Référentiel : La principale responsabilité est la conversion mutuelle entre les objets et le stockage, et le type peut être correctement abstrait, il n'est pas nécessaire que chaque modèle corresponde à un référentiel.
Meilleure pratique de la superposition d'architecture d'application DDD
1) Architecture d'application en couches
2) Capacité commerciale
Grâce à l'assemblage de capacités dans différents domaines (éventuellement à travers des organisations et des départements), certaines capacités commerciales peuvent être synthétisées, et un accès rapide via la configuration + la personnalisation peut accélérer l'itération commerciale
4. Idéologie directrice de la conception axée sur le domaine
1) Dans la couche de domaine, les concepts du domaine doivent être utilisés pour exprimer la logique métier, et toute la logique de domaine de base est implémentée sur la base des composants de domaine. Au lieu de s'appuyer directement sur des implémentations externes et de ne pas exposer des interfaces non pertinentes au monde extérieur, la couche de domaine devrait être l'objet de protection clé.
2) La couche référentiel ne participe généralement pas au contrôle des transactions.
3) Faites toujours attention à la conception et aux responsabilités du modèle de domaine, adhérez au principe SOLID de la conception orientée objet et n'utilisez pas les objets de domaine uniquement comme conteneurs de données.
4) Essayez de parcourir la base de données via la racine agrégée pour trouver l'objet de valeur associé au lieu de traverser directement l'objet de valeur. Si vous avez vraiment besoin d'ignorer l'entité et de parcourir directement l'objet de valeur, vous devez déterminer si la conception du modèle est déraisonnable et si l'objet de valeur doit être conçu comme une entité.
5) L'ensemble de la conception doit être à faible couplage et à haute cohésion, y compris la conception et la division de l'emballage.
6) La conception logicielle doit toujours lutter contre la complexité et laisser la conception complexe là où elle est vraiment nécessaire. La modélisation de domaine commence par la simplification des associations . L'association entre les modèles doit être la moins complexe possible. Ceux qui peuvent être associés un à plusieurs ne doivent pas être conçus comme des associations plusieurs à plusieurs, ceux qui peuvent être associés un à un ne doivent pas être conçus comme des associations un à plusieurs et ceux qui peuvent être associés à sens unique ne doivent pas être bidirectionnels. Lorsque la simplification n'est pas possible, demandez-vous si vous pouvez ajouter des conditions appropriées et réalistes, qui peuvent réduire la complexité de l'association. Plus l'association est complexe, plus il est difficile de garantir la cohérence des données, plus il est difficile de garantir la stabilité du système, et la complexité de mise en œuvre du système augmentera. Si la relation peut être correctement simplifiée, elle reflète également une compréhension approfondie de la connaissance du domaine. Les associations contraintes peuvent transmettre plus de connaissances et sont plus pratiques. Simplifier et limiter soigneusement les associations de modèles est le seul moyen d'obtenir une conception axée sur le domaine.
7) Concevoir la structure de stockage des données en fonction des besoins des entités et des objets de valeur. En règle générale, les informations liées au modèle de domaine 1-à-1 peuvent être stockées dans une table de données, à moins que de grands champs ne soient séparés dans différentes tables. Les données 1 à plusieurs ne peuvent être séparées que dans différentes tables. La conception de la base de données doit respecter : rendre nos requêtes et mises à jour de données plus efficaces et garantir l'intégrité des données de manière plus sécurisée.
8) En plus d'accéder aux objets associés dans l'agrégat via la racine agrégée, il n'est pas permis d'accéder à d'autres objets dans l'agrégat d'une autre manière