¿Qué es DDD (Diseño Dirigido por Dominio)? Este es el artículo más comprensible sobre DDD que he visto en mi vida.

Agregar navegación. Consulte este artículo para obtener ideas detalladas sobre cómo diseñar agregaciones.

En 2004, Eric Evans publicó "Diseño basado en dominios: resolver la complejidad en el núcleo del software" (Evans DDD para abreviar). El diseño basado en dominios se divide en dos etapas:

Usar un lenguaje común que los expertos en dominios, diseñadores y desarrolladores puedan entender como una herramienta para la comunicación mutua, descubrir conceptos de dominio durante el proceso de comunicación y luego convertirlos. Estos conceptos están diseñados en modelos de dominio;

El diseño de software está impulsado por modelos de dominio y los modelos de dominio se implementan mediante código;

Por lo tanto, el núcleo del diseño impulsado por dominio es para establecer un modelo de dominio correcto.

¿Por qué es importante construir un modelo de dominio?

El diseño impulsado por dominio nos dice que al implementar sistemas empresariales a través de software, es muy importante y necesario establecer un modelo de dominio, porque el modelo de dominio tiene las siguientes características:

00001 .? Un modelo de dominio es una abstracción de un dominio con ciertos límites, que refleja la naturaleza de las necesidades comerciales de los usuarios en el dominio. El modelo de dominio está acotado y solo refleja las partes del dominio que nos interesan;

00002.? El modelo de dominio solo refleja el negocio y no tiene nada que ver con ninguna implementación técnica; el modelo de dominio no solo puede reflejar algunos conceptos físicos en el dominio, como productos, libros, registros de aplicaciones, direcciones, etc. También puede reflejar algunos conceptos de proceso en este campo, como transferencias de fondos, etc.

00003.? El modelo de dominio garantiza que la lógica empresarial de nuestro software esté en un modelo y en un solo lugar; esto es muy útil para mejorar la mantenibilidad, la comprensibilidad empresarial y la reutilización del software;

00004.? Los modelos de dominio pueden ayudar a los desarrolladores a transformar el conocimiento del dominio en construcciones de software con relativa facilidad;

00005.? Los modelos de dominio se ejecutan durante todo el proceso de análisis, diseño y desarrollo de software. Los expertos, diseñadores y desarrolladores del dominio se comunican a través de modelos de dominio y comparten conocimientos e información entre sí, porque todos enfrentan el mismo modelo, lo que puede evitar que se cumplan los requisitos; sesgado. Deje que los diseñadores y desarrolladores de software creen software que realmente satisfaga las necesidades;

00006.? Establecer un modelo de dominio correcto no es fácil. Requiere comunicación activa y esfuerzos por parte de expertos, diseñadores y desarrolladores del dominio para profundizar la comprensión del dominio y refinar y mejorar el modelo de dominio.

00007.? Para hacer visible un modelo de dominio, debemos expresarlo de alguna manera; los diagramas son la forma más común de expresar modelos de dominio, pero no son la única. Las descripciones de código o textuales también pueden expresar modelos de dominio.

00008.? El modelo de dominio es el núcleo de todo el software y la parte más valiosa y competitiva del software. Un modelo de dominio bien diseñado que satisfaga las necesidades comerciales puede responder más rápido a los cambios en los requisitos;

Lenguaje ubicuo (lenguaje universal)

Nos damos cuenta de que los expertos en software y los expertos en el dominio colaboran en el desarrollo de un dominio. El modelo es absolutamente necesario, pero este enfoque suele ser difícil debido a algunas barreras de comunicación fundamentales. La mente de los desarrolladores está llena de clases, métodos, algoritmos, patrones, arquitecturas, etc. , y siempre quieren corresponder a conceptos y artefactos procedimentales en la vida real. Quieren entender qué clases de objetos construir y cómo modelar las relaciones entre clases de objetos. Estarán acostumbrados a pensar en términos de conceptos de programación orientada a objetos, como encapsulación, herencia y polimorfismo, y hablarán así en cualquier momento y en cualquier lugar. Esto es normal para ellos. Los desarrolladores son desarrolladores. Pero los expertos en el campo a menudo no saben nada al respecto. No tienen conceptos de bibliotecas de software, marcos, persistencia o incluso bases de datos. Sólo conocen su propia y única experiencia en el dominio. Por ejemplo, en el caso del monitoreo del tráfico aéreo, los expertos en el dominio conocen la aeronave, la ruta, la altitud, la longitud y la latitud, saben si la aeronave se desvía de la ruta normal y conocen el despegue de la aeronave. Discuten estas cosas en sus propios términos, que a veces son difíciles de entender directamente para los legos. Si una persona dice algo que los demás no entienden, o peor aún, lo malinterpretan como otra cosa, ¿qué posibilidades hay de garantizar el éxito del proyecto?

En el proceso de comunicación, se necesita traducción para que otras personas comprendan estos conceptos. Los desarrolladores pueden intentar analizar algunos patrones de diseño utilizando un lenguaje sencillo, pero esto no siempre tiene éxito. Los expertos en el campo también pueden crear una nueva jerga para intentar expresar estas ideas.

Este tipo de traducción no puede ayudar al proceso de construcción del conocimiento en este doloroso proceso de comunicación.

La perspectiva de pensar en los problemas en el modelado de dominios

Las "necesidades del usuario" no pueden equipararse con los "usuarios", y capturar "el modelo en la mente del usuario" no puede equipararse con " campo de diseño centrado en el usuario"Modelo". Hay un punto de vista en "Laozi": si crees que es útil, pensarás que es inútil. La ventaja aquí es establecer un modelo de dominio; de lo contrario, se adapta a las necesidades del usuario. Por ejemplo, una taza debe llenarse con un vaso de agua. Cuando hacemos tazas, las vacíamos. Tenemos que vaciar el agua antes de poder ponerla en el agua. Otro ejemplo: la casa necesita gente. Cuando construimos una casa, la casa está vacía, y sólo cuando está vacía la gente puede vivir en ella. Por lo tanto, al construir un modelo de dominio, los usuarios también deben ubicarse fuera del modelo para satisfacer sus necesidades.

Entonces, según entiendo:

00001.? Cuando diseñamos un modelo de dominio, no podemos pensar en los problemas desde la perspectiva de los usuarios y no siempre podemos pensar en lo que los usuarios le harán al sistema. Más bien, es necesario explorar cosas relevantes en el campo desde una perspectiva objetiva basada en las necesidades de los usuarios, y pensar en las relaciones esenciales y los patrones cambiantes de estas cosas como punto de partida para pensar en los problemas.

00002.? El modelo de dominio es un modelo mundial objetivo que excluye a las personas, pero incluye los roles de participación desempeñados por las personas, pero en términos generales, los roles de participación no deben ocupar una posición dominante en el modelo de dominio. Si el papel participante desempeñado por los humanos ocupa una posición dominante en el modelo de dominio, entonces los modelos de dominio de cada sistema serán difíciles de distinguir, porque el sistema de software es un sistema de interacción humano-computadora, y todas las actividades son registradas o rastreadas principalmente por humanos. Por ejemplo, si las personas dominan el foro, entonces el modelo de dominio es: las personas publican, las personas responden, las personas adjuntan, etc., tomando DDD como ejemplo, si las personas son el centro, se convierte en: los transportistas envían mercancías, el destinatario recibe la bienes, el pagador paga, etc., cuando hablamos del modelo de dominio, el factor humano ha sido excluido por defecto, porque el dominio sólo tiene significado para las personas, y las personas están fuera del alcance del dominio. Si se incluye a las personas en el dominio, será difícil que el modelo de dominio siga siendo objetivo. Un modelo de dominio es un modelo objetivo, independiente de quién lo usa y cómo se usa. En resumen, el modelado de dominio consiste en construir un modelo virtual para que lo usemos en la vida real, en lugar de construir un espacio virtual para imitar la realidad.

Jerarquía clásica del diseño basado en dominio

Interfaz de usuario/capa de presentación

Responsable de presentar información al usuario e interpretar los comandos del usuario. Más detalladamente, es:

00001.? Solicitar a la capa de aplicación obtener los datos que el usuario necesita mostrar;

00002.? Envíe comandos a la capa de aplicación para pedirle que ejecute comandos de usuario;

Capa de aplicación

Una capa delgada que define todas las tareas que debe completar el software. Externamente, proporciona varias funciones de aplicación (incluidas consultas o comandos) para la capa de presentación e internamente llama a la capa de dominio (objetos de dominio o servicios de dominio) para completar diversas lógicas comerciales. La capa de aplicación no contiene lógica comercial.

Capa de dominio

es responsable de expresar conceptos comerciales, información de estado comercial y reglas comerciales. El modelo de dominio se encuentra en esta capa y es el núcleo del software empresarial.

Capa de infraestructura

Esta capa proporciona capacidades técnicas generales para otras capas; proporciona comunicación entre capas; implementa el mecanismo de persistencia de la capa de dominio; la arquitectura y los marcos respaldan los requisitos técnicos de otras capas;

Patrones utilizados en el diseño basado en dominios

Descripción general de todos los patrones

Diseño asociativo

Asociación No es un patrón en sí mismo, pero es muy importante en el proceso de modelado de dominio, por lo que antes de discutir varios patrones, es necesario discutir cómo diseñar la asociación entre objetos. Creo que el diseño de asociación de objetos puede seguir los siguientes principios:

00001.? Cuantas menos asociaciones, mejor. Las asociaciones complejas entre objetos pueden formar fácilmente una red de relaciones de objetos, lo que no favorece nuestra comprensión y mantenimiento de los objetos individuales, y también es difícil distinguir los límites entre los objetos. al mismo tiempo ayuda a simplificar la relación entre objetos. Recorrido entre;

00002.? Las relaciones de muchos a muchos pueden ser naturales en los negocios. Generalmente usamos un conjunto para representar la relación de muchos a muchos de 1.

Sin embargo, a menudo necesitamos considerar problemas de rendimiento, especialmente cuando hay muchos elementos en la colección. En este momento, a menudo es necesario obtener la información de la colección asociada mediante una consulta separada;

00003.? Intente mantener asociaciones unidireccionales;

00004.? Al establecer una asociación, debemos profundizar más para ver si existe alguna restricción sobre la asociación. De ser así, lo mejor sería agregar este límite a la asociación. A menudo, tales restricciones pueden simplificar las asociaciones, es decir, muchos a muchos se pueden simplificar a 1-muchos, o 1-muchos se puede simplificar a 1 a 1;

Entidad

Entidad es un concepto de dominio, se requiere un identificador único en el dominio. Porque a veces necesitamos distinguir de qué entidad se trata. Hay dos entidades si sus identidades únicas son diferentes, incluso si todos los demás atributos de las entidades son iguales, las consideramos dos entidades diferentes porque las entidades tienen un ciclo de vida, pueden persistir en la base de datos y luego recuperarse en. un tiempo determinado. Por lo tanto, si no definimos un identificador único para una entidad, entonces no podemos saber si es esta entidad o qué entidad.

Además, no defina demasiados atributos o comportamientos para las entidades, sino busque asociaciones, encuentre otras entidades u objetos de valor y pase atributos o comportamientos a otras entidades u objetos de valor asociados. Por ejemplo, la entidad del cliente tiene cierta información de dirección. Debido a que la información de dirección es un concepto completo con importancia comercial, podemos definir un objeto de dirección y luego pasar información relacionada con la dirección del cliente al objeto de dirección. Si no hay un objeto de dirección, pero la información de la dirección se coloca directamente en el objeto del cliente, y si alguna otra información similar a una dirección también se coloca directamente en el cliente, el objeto del cliente será confuso, poco claro en estructura y, en última instancia, difícil de entender. mantener y comprender;

Objeto de valor (Objeto de valor)

En el campo, no todo debe tener una identidad única, es decir, no nos importa qué objeto es qué, pero sólo lo que es. Tome el objeto de dirección anterior como ejemplo. Si dos clientes tienen la misma información de dirección, asumiremos que las direcciones de los dos clientes son las mismas. En otras palabras, siempre que la información de la dirección sea la misma, consideramos que es la misma dirección. Expresado de forma programática, si todas las propiedades de dos objetos tienen el mismo valor, los consideraremos como el mismo objeto, entonces podemos diseñar este objeto como un objeto de valor. Por lo tanto, el objeto de valor no tiene un identificador único, que es la mayor diferencia entre este y la entidad.

Además, un objeto de valor se juzga por si todos sus atributos son iguales. Si son iguales, se considera que es el mismo objeto de valor cuando distinguimos si son la misma entidad; solo miramos si los identificadores únicos de las entidades son los mismos, independientemente de si los atributos de la entidad son los mismos. Otra característica obvia del objeto de valor es la inmutabilidad, es decir, todos los atributos son de solo lectura. Debido a que el atributo es de solo lectura, * * * * se puede disfrutar con confianza * * * al disfrutar de un objeto de valor, generalmente existen dos métodos: copiar y * * * disfrutar El método específico depende de la situación real; Además, el objeto de valor debe ser lo más simple posible y no permitir que haga referencia a muchos otros objetos, porque es solo un valor, al igual que int a = 3, entonces "3" es un valor en nuestro; En el sentido tradicional, el objeto de valor aquí en realidad puede entenderse como "3" "también es un valor, pero está representado por un objeto. Entonces, cuando comparamos dos objetos de valor en lenguaje C# para ver si son iguales, para comparar los valores de los objetos, anularemos los métodos GetHashCode y Equals. Aunque el objeto de valor es de solo lectura, se puede reemplazar por completo. Así como cambia el valor de A a "4" (A = 4;), reemplace directamente el valor de "3" con "4". Lo mismo ocurre con los objetos de valor. Cuando quieras modificar la referencia del objeto de dirección del cliente, no lo hagas a través del cliente. Address.Street, debido a que el objeto de valor es de solo lectura, es un todo completo e indivisible. Podemos hacer esto: clientes.

Dirección = nueva dirección(…);

Servicio de capa de aplicación

00001.? Obtener información (como una solicitud XML);

00002.? Enviar un mensaje al servicio de capa de dominio, exigiéndole que implemente llamadas de lógica empresarial;

00003.? Si el servicio de capa de dominio se procesa correctamente, se llama al servicio de capa base para enviar una notificación por correo electrónico;

Servicio de capa de dominio

00001.? Obtenga la cuenta de origen y la cuenta de destino, y notifique a la cuenta de origen y a la cuenta de destino respectivamente para realizar operaciones de deducción y suma;

00002.? Proporcionar los resultados devueltos a la capa de aplicación;

Servicio de capa básica

Enviar notificaciones por correo electrónico de acuerdo con la solicitud de la capa de aplicación;

Así queda claro desde En el ejemplo anterior se puede ver que las responsabilidades de cada servicio;

Agregación y raíz de agregación (agregación)

La agregación logra la cohesión del modelo de dominio al definir atribuciones y límites claros entre Evite crear redes complejas de relaciones de objetos que sean difíciles de mantener. Un agregado define un conjunto de objetos relacionados con una relación cohesiva y tratamos el agregado como una unidad para modificar datos.

La agregación tiene las siguientes características:

00001.? Todo agregado tiene una raíz y un límite. Los límites definen entidades u objetos de valor en un agregado. La raíz es una entidad en el agregado.

00002.? Los objetos dentro de un agregado pueden hacer referencia entre sí, pero si el exterior del agregado quiere acceder a un objeto dentro del agregado, debe comenzar a navegar a través de la raíz del agregado, y es absolutamente imposible acceder directamente a un objeto dentro del agregado sin omitir el raíz agregada, lo que significa que la raíz agregada es el único elemento al que se puede mantener una referencia externa.

00003.? Los identificadores únicos para entidades en un agregado distinto de la raíz son identificadores locales, es decir, siempre que sigan siendo únicos dentro del agregado, ya que siempre están subordinados a ese agregado;

00004.? La raíz agregada es responsable de procesar otros objetos externos y mantener sus propias reglas comerciales internas;

00005.? Con base en el concepto de agregación anterior, podemos inferir que la unidad al consultar desde la base de datos también es una unidad de agregación, lo que significa que no podemos consultar directamente el objeto no raíz dentro de un agregado;

00006. ? Los objetos en un agregado pueden mantener referencias a otras raíces agregadas;

00007.? Al eliminar una raíz agregada, debe eliminar todos los objetos relacionados en el agregado al mismo tiempo, porque todos pertenecen a un agregado y son un concepto completo;

¿Cómo identificar la raíz agregada?

Si un agregado tiene solo una entidad, entonces esta entidad es la raíz del agregado, si hay varias entidades, entonces podemos pensar en qué objeto del agregado tiene el significado de existencia independiente y puede estar directamente relacionado; a la interacción externa.

Fábrica

La fábrica DDD es también un modelo que encarna el concepto de embalaje. La razón por la que se introdujo el patrón de fábrica en DDD es que a veces la creación de un objeto de dominio es compleja y no solo una nueva operación simple. Así como un objeto encapsula su implementación interna (podemos usar su comportamiento sin conocer su implementación interna), una fábrica se usa para encapsular el conocimiento requerido para crear un objeto complejo, especialmente un agregado, cuyo propósito es ocultar los detalles de creando un objeto. El cliente pasa algunos parámetros simples a la fábrica, y la fábrica puede crear internamente un objeto de dominio complejo y devolverlo al cliente.

Otros elementos del modelo de dominio no son adecuados para esto, por lo que necesitamos introducir este nuevo modelo, la fábrica. Cuando una fábrica crea un objeto de dominio complejo, generalmente sabe qué reglas comerciales debe cumplir (sabe cómo crear una instancia de un objeto primero y luego qué operaciones de inicialización hacer con él, cuáles son los detalles de la creación del objeto). Si los parámetros pasados ​​se ajustan a las reglas comerciales para crear el objeto, el objeto correspondiente se puede crear exitosamente; sin embargo, si el objeto esperado no se puede crear debido a parámetros no válidos y otras razones, se debe lanzar una excepción para garantizar que se generen objetos incorrectos; no creado. Por supuesto, no siempre necesitamos usar una fábrica para crear objetos. De hecho, la creación de objetos de dominio no es demasiado complicada en la mayoría de los casos. Solo necesitamos usar el constructor para crear el objeto. El beneficio de ocultar los objetos creados es obvio, de modo que la lógica empresarial de la capa de dominio no se filtrará a la capa de aplicación y también se puede reducir la carga de la capa de aplicación. Simplemente llama a la fábrica de dominios para crear los objetos necesarios.

Almacenamiento (Repositorio)

00001.? El propósito del diseño del almacén es por esta razón: los objetos en el modelo de dominio no permanecen activos en la memoria desde el momento en que se crean, sino que persisten en la base de datos cuando están inactivos y luego reconstruimos los objetos cuando es necesario; objetos es el proceso de recrear objetos en función del estado del objeto almacenado en la base de datos, por lo que se puede ver que reconstruir objetos es un proceso de procesamiento de la base de datos; Desde una perspectiva más amplia, a menudo obtenemos uno o algunos objetos de un lugar similar a una colección, agregamos objetos a la colección o eliminamos objetos según ciertas condiciones. En otras palabras, necesitamos proporcionar un mecanismo que pueda proporcionar una interfaz similar a una colección para ayudarnos a administrar objetos. El almacenamiento se diseña en base a esta idea;

Pasos generales para diseñar modelos de dominio

00001.? Establezca un modelo de dominio preliminar basado en los requisitos y determine algunos conceptos de dominio obvios y sus relaciones. Es posible que la asociación no tenga una dirección por el momento, pero necesita tener estas relaciones (1: 1, 1: n, m: n). Puede utilizar palabras para describir con precisión el significado de cada concepto de dominio y la información principal que contiene;

00002.? Analizar las principales funciones de la aplicación de software y determinar las principales clases de la capa de aplicación; esto ayuda a descubrir tempranamente cuáles son las responsabilidades de la capa de aplicación y cuáles son las responsabilidades de la capa de dominio;

00003.? Analice más a fondo el modelo de dominio para determinar cuáles son entidades, cuáles son objetos de valor y cuáles son servicios de dominio;

00004.? Analizar correlaciones, aclarar la dirección de las correlaciones o eliminar algunas correlaciones innecesarias mediante un análisis más profundo del negocio y varios principios de diseño de software y compensaciones de rendimiento;

00005.? Encontrar los límites y las raíces de los grupos es muy difícil. Debido a que a menudo se encuentran muchas opciones ambiguas que son difíciles de juzgar con claridad durante el proceso de análisis, es necesario que acumulemos algo de experiencia en análisis en la vida diaria y encontremos la raíz agregada correcta;

00006.? Aprovisione un repositorio para la raíz agregada. Normalmente, un almacén se asigna a un resumen. En este momento, solo necesitas diseñar la interfaz del almacén.

00007.? Explore los escenarios para garantizar que el modelo de dominio que diseñamos pueda resolver eficazmente las necesidades comerciales;

00008.? Considere cómo se crean las entidades de dominio u objetos de valor, ya sea a través de una fábrica o directamente a través de un constructor;

00009.? Detenga y reconstruya el modelo. ¿Encuentra algunos problemas o lugares incómodos en el modelo, como pensar si algunos objetos deben obtenerse mediante navegación asociativa o desde el almacén? ¿Es correcto el diseño de agregación? Considere el rendimiento del modelo, etc.;

Varios métodos de implementación de unidades de trabajo

00001.? Según la implementación de instantáneas, es decir, después de extraer el objeto de dominio, primero se guardará un objeto de respaldo y luego se comparará el estado del último objeto con el estado del objeto de respaldo durante la operación de persistencia. Si es diferente, se considera modificado y luego persiste. La ventaja de este diseño es que el objeto no necesita decirle a la unidad de trabajo que su estado ha sido modificado, pero la desventaja también es obvia, es decir, el rendimiento puede ser menor, y cuando el objeto en sí es complejo, si el El estado del objeto de copia de seguridad y el objeto de comparación se han modificado. El proceso suele ser un paso que requiere mucho tiempo y todavía es difícil implementar realmente una copia profunda del objeto y determinar si las propiedades se han modificado.

00002.? No se basa en una instantánea, pero cuando se llama a la interfaz de actualización o adición o eliminación relevante del almacén, el almacén notifica a la unidad de trabajo que se ha agregado, actualizado o eliminado un objeto. De esta manera, la unidad de trabajo también puede saber qué objetos deben persistir al realizar la persistencia de datos. En teoría, este método no requiere el soporte del marco ORM, no tiene ninguna inclinación hacia el modelo de dominio y también tiene un buen soporte; para el modelo de unidad de trabajo. Este método es bueno para aquellos que no desean utilizar un marco ORM avanzado;

Para funciones de consulta que no afectarán el estado de los objetos de dominio en la capa de dominio

Puede Consulta directamente a través del almacén de datos requeridos. Es posible que la función de consulta proporcionada por el almacén de la capa de dominio general no satisfaga las necesidades de visualización de la interfaz y puede ser necesario llamar a diferentes almacenes varias veces para obtener los datos que deben mostrarse. De hecho, para este tipo de consulta, yo; Hablaremos de ello más adelante. Se puede implementar directamente a través de la arquitectura CQRS.

En otras palabras, para consultas, podemos completar la consulta directamente a través de algún otro motor de consulta implementado por otra arquitectura técnica, sin llamar a nada en la capa de dominio en la capa de aplicación, como a través del constructor SQL parametrizado. consulta directamente cualquier dato que queramos mostrar de una tabla o de varias tablas en la base de datos. Esto no sólo proporciona un alto rendimiento, sino que también reduce la carga en la capa de dominio. El modelo de dominio no es adecuado para proporcionar diversos servicios de consulta para la capa de aplicación, porque los datos que se mostrarán en la interfaz suelen ser una combinación de muchos objetos, que es un tipo de información conceptual que no es un objeto, como un informe;

Orientado La esencia de los objetos es la división y encapsulación de límites, que no solo puede cuantificar los cambios en los requisitos y reducir el área de impacto, porque la división de límites también limitará el alcance de los errores, y OO también es beneficioso para errores y otros; errores en las últimas etapas del software.

Siempre habrá errores en el mundo del software y los errores no se pueden eliminar, al igual que siempre habrá imperfecciones y lados oscuros en el mundo humano. La clave del problema es: Dios usa los límites del espacio y el tiempo para limitar las imperfecciones del mundo humano, como el sufrimiento y los desastres, dentro de un cierto rango en el mundo del software, si los límites no se dividen utilizando métodos como OO; , una vez que algo sale mal, se rastreará. ¿Qué tan malo podría ser?

De hecho, el mundo del software es similar al mundo real humano y, a veces, pueden ocurrir errores. Cuando analizamos las razones, resulta que son causadas por dos factores aparentemente no relacionados. Los antiguos a menudo rezaban a los dioses y adoraban a Buda. Cuando nuestro software se ejecuta en Internet, los programadores probablemente estemos rezando a Dios y rezando a Buda para que no cometa grandes errores. Si nuestro software utiliza paquetes OO, estaremos más tranquilos y definitivamente ocurrirán errores, pero hemos trazado los límites de antemano, por lo que no habrá consecuencias graves.

Modo de análisis de prototipo de cuatro colores

Prototipo de intervalo de momento

Representa actividades que ocurren en un momento determinado o dentro de un período de tiempo determinado. En rosa, abreviado como MI.

Parte del prototipo de lugar y cosa

Significa las personas o cosas que participan en la actividad, y el lugar es el lugar donde se desarrolla la actividad. Indicado en verde. La abreviatura de PPT.

Prototipo de descripción

Representa la descripción esencial de PPT. ¡No es una clasificación PPT! La descripción es un conjunto de atributos inmutables extraídos de PPT. Se muestra en azul y se abrevia como DESC.

Por ejemplo, hay una persona llamada Zhang San. ¿Qué pasa si un extraterrestre te pregunta qué es Zhang San? ¿Qué dirías? Se puede decir que Zhang San es un ser humano y los extraterrestres no saben qué es "humano". Entonces, ¿qué harías? Dirías: Zhang San es una existencia objetiva compuesta de una cabeza, dos manos, dos pies y un cuerpo. Aunque los extraterrestres no saben qué son los humanos en este momento, ya puedo usar este ejemplo para explicar qué es "descripción". En este ejemplo, Zhang San es un PPT "Una existencia objetiva que consta de una cabeza, dos manos, dos pies y un cuerpo" es la descripción de Zhang San. La cabeza, las manos, los pies y el cuerpo son atributos inmutables de la naturaleza humana. recopilación. Pero los humanos somos inteligentes y buenos para generalizar y nombrar conceptos abstractos. Cambiamos esta descripción a una palabra, que es "personas". Por eso hay un dicho que dice que Zhang San es un ser humano.

Prototipo de rol

Un rol es lo que habitualmente entendemos como “identidad”. Utilice amarillo, abreviado como Rol. ¿Por qué existe el concepto de rol? Porque para algunas actividades, solo los PPT (participantes) con roles (identidades) específicos pueden participar en esta actividad. Por ejemplo, una persona sólo puede ir a clase (una actividad) si tiene el rol de profesor; una persona puede participar en las elecciones y ser elegida sólo si es un ciudadano legal pero algunas actividades no requieren un rol, como por ejemplo; como dormir solo sin ningún rol (una actividad). Por supuesto, también es un error decir que se puede dormir sin un papel. ¿Qué ocurre? Porque podemos entender que una existencia objetiva puede dormir siempre que tenga el rol de "persona". De hecho, en este momento ya hemos considerado a DESC como un rol. Por lo tanto, de hecho, el concepto de rol es muy amplio y no puede entenderse con el sentido estricto de "identidad" que generalmente entendemos, porque "maestro", "ciudadano legal" y "persona" pueden considerarse roles. Por tanto, cabe decir que cualquier actividad requiere de participantes con determinados roles para participar.

Resumir el arquetipo de los cuatro colores en una frase es: qué tipo de personas, organizaciones u objetos participan en una determinada actividad en un determinado rol en un determinado momento o en un determinado período de tiempo. Entre ellos, "qué" es DESC, "persona u organización u objeto" es PPT, "rol" es rol y "una actividad en un determinado momento o período de tiempo" es MI.

Si estudias estas cosas después de aprender DDD, tendrás una comprensión más profunda de DDD, pero creo que DDD es relativamente básico y será más efectivo estudiar estas cosas después de comprender DDD. dominar.