Article sérialisé DDD
Pourquoi les débutants DDD tombent-ils malades immédiatement après s'en être débarrassés Que dit Eric Evans de la définition de la conception pilotée par domaine Quelle est l'expression de la connaissance du domaine dans un modèle Quelle est l'architecture la plus accessible pour démarrer avec la conception pilotée par domaine Présentation de l'architecture Domain Driven + Onion

introduction

Nous parlerons de la manière de percevoir un «modèle» dans la conception axée sur le domaine et de la nécessité d'un contexte limité.

«Contexte borné» est un point très important mais difficile à comprendre dans la conception pilotée par domaine, je vais donc essayer de faciliter la compréhension de sa nécessité et de sa définition.

Qu'est-ce qu'un modèle?

Nous entendons souvent les mots «modèle» et «modélisation» dans le développement de logiciels, mais je pense que certaines personnes ne se sont jamais arrêtées et n'ont jamais réfléchi à la définition.

Si vous essayez de google la définition en japonais, il semble que l'on en parle souvent dans le contexte d'UML. Puisqu'il s'agit d'un mot abstrait, je pense qu'il existe différentes définitions, mais je vais citer la définition de l'article de Nikkei Computer.

Rapport informatique (cours de 3 minutes sur les mots clés) - Modélisation

Une technique de construction de système pour visualiser des choses invisibles telles que le flux commercial et la structure du système.
Créez une vue en plan (modèle) à l'aide de symboles.

Le modèle est écrit *** pour visualiser ce qui est invisible.

Je pense que c'est également correct dans certains contextes, mais lors de la modélisation axée sur le domaine, il peut être préférable d'être un peu prudent.

*** Modélisation = Pas une représentation correcte de ce qui est dans le monde réel ***

à propos de ça.

Définition de Eric Evans

Jetez un œil à la référence DDD d'Eric Evans (http://domainlanguage.com/ddd/reference/).
(Qu'est-ce que ce document Que dit Eric Evans sur la définition de la conception pilotée par domaine J'ai écrit dans l'article)

model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain Un résumé qui représente un aspect particulier du domaine d'intérêt et est utilisé pour résoudre des problèmes connexes

L'important est que le modèle
représente *** aspects sélectionnés *** et
le but est *** de résoudre le problème associé *** c'est comme ça.

Abstraire un événement particulier est fondé sur le fait qu'il est «impossible de le décrire avec précision» parce qu'il enlève diverses choses concrètes. Alors, que visez-vous sans viser la précision?
C'est *** si cela répond à l'objectif de résolution de problèmes ***.

Je pense que c'est un peu différent de "visualiser" en nuance.

Étude de cas

À titre d'exemple, dans Domain Driven Design (en.wikipedia), il y a une telle description sur la différence entre Entity et Value Object. (J'écrirai un article sur la définition d'entité et de ValueObject plus tard)

Example:
Most airlines distinguish each seat uniquely on every flight. Each seat is an entity in this context.
However, Southwest Airlines, EasyJet and Ryanair do not distinguish between every seat; all seats are the same. In this context, a seat is actually a value object. La plupart des compagnies aériennes distinguent chaque siège de manière unique sur chaque vol. Dans ce contexte, chaque siège est une entité.
Cependant, Southwest Airlines, EasyJet et Ryanair ne distinguent pas tous les sièges et tous les sièges sont les mêmes. Dans ce contexte, un siège est un objet de valeur.

Si vous souhaitez simplement "visualiser" les sièges d'un avion, ils doivent être du même modèle car ce sont des sièges.
Cependant, dans ce cas, la même chose physiquement a été reconnue comme un modèle en fonction de la politique de service de la société d'exploitation.

Cela signifie que chaque contexte de résolution de problème a changé l'aspect du focus et le modèle défini.

Limiter le champ d'application du modèle

Il s'avère que différentes compagnies aériennes peuvent avoir des perceptions différentes du modèle. Le modèle est-il donc toujours unifié au sein d'une même compagnie aérienne?

Même si vous imaginez un peu, il semble que l'équipe qui crée physiquement les «sièges» et l'équipe qui gère les réservations pour les «sièges» ont des points de vue différents sur la façon de résoudre le problème des «sièges».

Si la même gamme de reconnaissance de modèles ne peut pas être universelle et qu'il ne s'agit pas d'une unité d'entreprise, s'agit-il d'un département? équipe? En premier lieu, cela dépend de la personne ...?

En réfléchissant de cette façon, vous pourriez arriver à la conclusion que *** le champ d'application du modèle doit être défini explicitement ***. Cette démarcation explicite est appelée *** contexte borné *** dans la terminologie de la conception axée sur le domaine.

Voir la définition dans la référence DDD d'Eric Evans (http://domainlanguage.com/ddd/reference/).

bounded context: A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
Contexte borné:
Une description des limites (généralement des sous-systèmes, ou le travail d'une équipe particulière) auxquelles un modèle particulier est défini et appliqué.

La conception axée sur le domaine attache une grande importance à ce contexte limité. Comme mentionné ci-dessus, aucun modèle ne peut être défini correctement sans cette limite.

Il définit ensuite comment les contextes sont liés les uns aux autres. L'artefact s'appelle une carte de contexte. Il s'agit de la base de conception principale pour la conception pilotée par domaine.

Résumé

Nous avons défini le modèle comme une correspondance de reconnaissance de mots et décrit le contexte déroutant lié aux mots de DDD.

Comment le contexte limité sera-t-il intégré dans la mise en œuvre à l'avenir? J'aimerais écrire.