¿Qué es DDD (Diseño Dirigido por Dominio)? Este es el artículo sobre DDD más fácil de entender que he visto en mi vida.
Modelo de dominio de diseño basado en dominio
Agregar una navegación Para obtener ideas detalladas sobre cómo diseñar la agregación, consulte este artículo.
En 2004, Eric Evans publicó Domain-Driven Design –Tackling Complexity in the Heart of Software (Domain-Driven Design), conocido como Evans DDD. El diseño basado en dominios se divide en dos etapas:
Utilizar 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 Estos conceptos están diseñados en un modelo de dominio;
El modelo de dominio impulsa el diseño del software y el código se utiliza para implementar el modelo de dominio;
Se puede ver que el núcleo del dominio El diseño impulsado es establecer el modelo de dominio correcto.
Por qué es importante establecer un modelo de dominio
El diseño basado en dominio nos dice que al implementar un sistema empresarial a través de software, es muy importante y necesario establecer un modelo de dominio, porque el El modelo de dominio tiene las siguientes características:
00001. El modelo de dominio es una abstracción de un dominio con un límite determinado, que refleja la esencia de las necesidades comerciales del usuario en el dominio y solo tiene límites; refleja nuestra parte de preocupación en el campo;
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 de entidad en el campo; , como bienes, libros, registros de solicitudes, direcciones, etc., también puede reflejar algunos conceptos de proceso en el dominio, como transferencia de fondos, etc.;
00003. La lógica de nuestro software está toda en un modelo y en un solo lugar. Esto es muy útil para mejorar la capacidad de mantenimiento, la comprensión empresarial y la reutilización del software;
00004. ¿Los modelos de dominio pueden ayudar a los desarrolladores a transformar el dominio de manera relativamente fluida? conocimiento en la construcción de software;
00005.? Los modelos de dominio abarcan 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í; ; Debido a que todos enfrentan el mismo modelo, se puede evitar que los requisitos se distorsionen y el software creado por diseñadores y desarrolladores de software realmente puede satisfacer las necesidades;
00006. modelo de dominio correcto. Requiere comunicación activa y esfuerzos conjuntos por parte de expertos, diseñadores y desarrolladores del dominio, para que todos puedan tener una comprensión más profunda del dominio y perfeccionar y mejorar continuamente el modelo de dominio;
00007.? Para hacer el modelo de dominio, como puede ver, necesitamos usar algunos métodos para expresarlo; los diagramas son la forma más comúnmente utilizada para expresar modelos de dominio, pero no son la única forma de expresión que también pueden expresarse mediante códigos o descripciones de texto. modelos de dominio expresos;
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 que esté bien diseñado y satisfaga las necesidades comerciales puede responder a la demanda; cambia más rápidamente;
Lenguaje común del dominio (LENGUAJE UBIQUITO)
Reconocemos que es absolutamente necesario que los expertos en software y los expertos en el dominio trabajen juntos para desarrollar un modelo de dominio, pero ese enfoque A menudo tiene dificultades debido a algunas barreras básicas de comunicación. Las mentes de los desarrolladores están llenas de clases, métodos, algoritmos, patrones, arquitecturas, etc., y siempre están tratando de mapear conceptos de la vida real para programar artefactos. Quieren ver qué clases de objetos se construirán y cómo se modelarán las relaciones entre las clases de objetos. Estarán acostumbrados a pensar en términos de conceptos de programación orientada a objetos como encapsulación, herencia, polimorfismo, etc., y hablarán así en cualquier momento y en cualquier lugar. Esto es normal para ellos. 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.
Solo conocen su experiencia en un dominio específico. Por ejemplo, en el ejemplo de monitoreo del tráfico aéreo, los expertos en el dominio conocen la aeronave, la ruta, la altitud, la longitud y la latitud, saben que la aeronave se desvió 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 otros no pueden entender, o peor aún, malinterpretan como otra cosa, ¿qué posibilidades tiene el proyecto de garantizar el éxito?
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 en términos sencillos, pero esto no siempre funciona. Los expertos en el dominio también pueden crear una nueva jerga en un esfuerzo por expresar estas ideas. Este tipo de traducción no contribuye al proceso de construcción de conocimiento en este doloroso proceso de comunicación.
La perspectiva de pensar en los problemas cuando se modela un dominio
Las "necesidades del usuario" no pueden equipararse con los "usuarios", ni capturar "el modelo en la mente del usuario" con " diseño centrado en el usuario"Modelo de Dominio". Hay un punto en el libro "Laozi": si tienes algo, te beneficiarás, pero si no lo tienes, lo usarás. Aquí lo beneficioso es establecer un modelo de dominio; lo inútil es adaptarse a las necesidades de los usuarios. Para dar algunos ejemplos, es necesario llenar una taza con una taza de agua. Cuando hacemos la taza, hacemos una taza vacía, es decir, tenemos que verter el agua antes de que se pueda llenar con agua. que una casa necesita ser habitada. Cuando construimos una casa, la casa construida está vacía y sólo el espacio vacío puede albergar a las personas. Por lo tanto, al construir un modelo de dominio, los usuarios también deben ubicarse fuera del modelo para que se puedan satisfacer sus necesidades.
Entonces, mi entendimiento es:
00001 Al diseñar el modelo de dominio, no podemos pensar en el problema con el usuario como centro, y no siempre podemos pensar en lo que es el usuario. qué le hará al sistema; en cambio, deberíamos desenterrar cosas relevantes en el campo en función de las necesidades del usuario desde una perspectiva objetiva, y pensar en las relaciones esenciales y los patrones cambiantes de estas cosas como punto de partida para pensar en el problema.
00002. El modelo de dominio es un modelo mundial objetivo que excluye a las personas, pero el modelo de dominio incluye los roles participantes desempeñados por las personas, pero generalmente no permite que los roles participantes ocupen el papel principal en la posición del modelo de dominio. , si el papel participante desempeñado por los humanos ocupa la posición principal en el modelo de dominio, entonces los modelos de dominio de cada sistema se volverán indistinguibles, porque el sistema de software es un sistema de interacción humano-computadora, y todos son registros de actividad centrados en el ser humano. O seguimiento; por ejemplo: si el foro está centrado en las personas, entonces el modelo de dominio es: publicaciones de personas, respuestas de personas, publicaciones de personas, etc., si está centrado en personas, se convierte en: remitente, remitente de mercancías, el destinatario recibe las mercancías, el pagador paga, etc., por lo tanto, cuando hablamos del modelo de dominio, el factor humano se ha excluido por defecto, porque el dominio solo tiene significado para las personas, y las personas están fuera del alcance del dominio, si las personas también están incluidas en el dominio, será difícil para el modelo de dominio mantener la objetividad. Un modelo de dominio es un modelo objetivo que no tiene nada que ver con quién lo usa y cómo se usa. En resumen, el modelado de dominio consiste en construir modelos virtuales para que los utilicen personas reales, en lugar de construir espacios virtuales para imitar la realidad.
Arquitectura en capas clásica de diseño basado en dominio
Interfaz de usuario/capa de presentación
Responsable de presentar información a los usuarios e interpretar los comandos del usuario. Más detalladamente:
00001. Solicitar a la capa de aplicación que obtenga los datos que el usuario necesita mostrar;
00002. Enviar un comando a la capa de aplicación para pedirle que ejecute un. ciertos comandos de usuario;
Capa de aplicación
Una capa muy delgada que define todas las tareas que el software necesita completar. 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 varias lógicas comerciales. La capa de aplicación no contiene lógica comercial.
Capa de dominio
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 comercial.
Capa de infraestructura
Esta capa proporciona capacidades técnicas generales para otras capas; proporciona comunicación entre capas; implementa un mecanismo de persistencia para la capa de dominio; en resumen, la capa de infraestructura puede Arquitectura y marco; para soportar los requisitos técnicos de otras capas;
Patrones utilizados en el proceso de diseño basado en dominio
Descripción general de todos los patrones
Diseño asociado
p>
La asociación en sí no es un patrón, pero es muy importante en el proceso de modelado de dominio, por lo que antes de explorar varios patrones, debemos discutir cómo diseñar la asociación entre objetos. Creo que el diseño de asociaciones de objetos puede seguir algunos de los siguientes principios:
00001 Debe haber la menor cantidad posible de asociaciones entre objetos que puedan formar fácilmente una red de objetos, lo cual es útil para nosotros. comprender y mantener un solo objeto es muy desventajoso y también es difícil distinguir los límites entre objetos; además, reducir las asociaciones al mismo tiempo ayuda a simplificar el recorrido entre objetos;
00002 .? Una asociación de muchos puede ser importante en los negocios. Naturalmente, normalmente utilizamos un conjunto para representar una relación de uno a muchos. Pero 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 a través de una consulta separada;
00003. mantenga la asociación unidireccional Association;
00004.? Al establecer una asociación, debemos profundizar más para ver si existe alguna restricción sobre la asociación. Si la hay, entonces es mejor agregar esto. restricciones a las asociaciones a menudo tales restricciones Las condiciones pueden simplificar las asociaciones, es decir, muchos a muchos se pueden simplificar a 1 a muchos, o 1 a muchos se pueden simplificar a 1 a 1;
Entidad
Una entidad es un concepto de dominio que debe identificarse de forma única en el dominio. Porque a veces necesitamos distinguir de qué entidad se trata. Hay dos entidades si los identificadores únicos son diferentes, incluso si todos los demás atributos de las entidades son iguales, las consideraremos dos entidades diferentes porque las entidades tienen un ciclo de vida y las entidades pueden persistir en la base de datos. después de que se creen. Luego se eliminará nuevamente en algún momento. Por lo tanto, si no definimos un identificador único para la entidad, entonces no podemos distinguir si es esta entidad o qué entidad.
Además, no debe definir demasiados atributos o comportamientos para las entidades. En su lugar, debe buscar asociaciones, descubrir otras entidades u objetos de valor y transferir atributos o comportamientos a otras entidades u objetos de valor asociados. . Por ejemplo, la entidad Cliente tiene cierta información de dirección. Dado que la información de dirección es un concepto completo con significado comercial, podemos definir un objeto Dirección y luego transferir la información relacionada con la dirección del Cliente al objeto Dirección. Si no hay un objeto Dirección y la información de la dirección se coloca directamente en el objeto Cliente, y si alguna otra información similar a la Dirección también se coloca directamente en el Cliente, el objeto Cliente se confundirá y, en última instancia, la estructura no será clara. lo que dificulta el mantenimiento y la comprensión;
Objeto de valor
En el campo, no todo debe tener un identificador único, lo que significa que no nos importa qué objeto es. preocuparse por cuál es el objeto. Tomando el objeto de dirección Dirección anterior como ejemplo, si la información de la dirección de dos clientes es la misma, pensaremos que las direcciones de los dos clientes son las mismas. Es decir, 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 los valores de todos los atributos de dos objetos son iguales, pensaremos que son el mismo objeto, entonces podemos diseñar dichos objetos como objetos de valor. Por lo tanto, un objeto de valor no tiene un identificador único, que es la mayor diferencia entre este y una entidad.
Además, al juzgar si un objeto de valor es el mismo objeto, se basa en si todos sus atributos son iguales. Si son iguales, se considera que son el mismo objeto de valor; distinguimos si son la misma entidad, solo miramos si el identificador único de la entidad es el mismo, independientemente de si los atributos de la entidad son los mismos. Otra característica obvia del objeto de valor es que es inmutable, que; es decir, todos los atributos son de sólo lectura. Debido a que el atributo es de solo lectura, se puede compartir de forma segura; cuando se comparte un objeto de valor, generalmente existen dos métodos: copiar y compartir. El método específico a adoptar depende de la situación real. objeto lo más simple posible y no permita que haga referencia a muchos otros objetos, porque es solo un valor, como int a = 3, entonces "3" es lo que llamamos un valor en el sentido tradicional. El objeto de valor en realidad puede entenderse como; Lo mismo que "3" aquí también es un valor, pero está representado por un objeto. Por lo tanto, cuando comparamos la igualdad de dos objetos de valor en el lenguaje C#, anularemos los métodos GetHashCode y Equals para comparar los valores de los objetos, aunque el objeto de valor es de solo lectura, se puede reemplazar por completo; . Así como cambió el valor de a a "4" (a = 4;), reemplaza directamente el valor de "3" con "4". Lo mismo ocurre con los objetos de valor. Cuando desea modificar la referencia del objeto Dirección del cliente, no puede hacerlo a través de Customer.Address.Street, porque el objeto de valor es de solo lectura y es un todo completo e indivisible. Podemos hacer esto: Customer.Address = new Address(...);
Servicio de capa de aplicación
00001.? Obtener información (como una solicitud XML);
00002.?Enviar un mensaje al servicio de capa de dominio y pedirle que implemente la lógica empresarial de la transferencia;
00003.?Si el servicio de capa de dominio se procesa correctamente, el servicio de capa base será llamado para enviar una notificación por correo electrónico;
Servicio de capa de dominio
00001.? Obtener la cuenta de origen y la cuenta de destino, y notificar a la cuenta de origen y a la cuenta de destino respectivamente para deducir el monto. y aumentar la cantidad;
00002.?Proporcionar los resultados devueltos a la capa de aplicación;
Servicios de capa básica
Enviar notificaciones por correo electrónico de acuerdo con las solicitudes de la capa de aplicación ;
Entonces, en el ejemplo anterior se puede ver claramente las responsabilidades de cada servicio;
Agregación y raíz agregada (Agregado, Raíz agregada)
Agregación, que implementa el modelo de dominio definiendo relaciones de propiedad claras y límites entre objetos. Es cohesivo y evita la formación de redes de relaciones de objetos intrincadas y difíciles de mantener. La agregación define un conjunto de objetos relacionados con una relación cohesiva. Consideramos una agregación como una unidad que modifica datos.
La agregación tiene las siguientes características:
00001. Cada agregado tiene una raíz y un límite. El límite define qué entidades u objetos de valor están dentro de un agregado. entidad;
00002.? Los objetos dentro de un agregado pueden hacer referencia entre sí, pero si desea acceder a un objeto dentro del agregado desde fuera del agregado, debe iniciar la navegación a través de la raíz del agregado y debe no omitir la raíz agregada. Acceda directamente a los objetos en el agregado, lo que significa que la raíz agregada es el único elemento que puede mantener una referencia a él desde el exterior;
00003.? las entidades en el agregado, excepto la raíz, son identificadores locales, y eso es, siempre que sigan siendo únicas dentro del agregado, porque siempre están subordinadas a este agregado;
00004.? tratar con otros objetos externos y mantener sus propias reglas comerciales internas;
00005 Con base en los conceptos de agregación anteriores, podemos inferir que la unidad al consultar desde la base de datos también se agrega en una unidad, lo que significa. que no podemos consultar directamente un objeto que no sea raíz dentro del agregado;
00006.?Los objetos dentro de un agregado pueden mantener referencias a otras raíces agregadas;
00007.?Al eliminar un agregado raíz, también debe eliminar todos los objetos relacionados en el agregado porque todos pertenecen al mismo Un agregado es 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 múltiples entidades, entonces podemos pensar en qué objeto del agregado tiene un significado independiente y puede interactuar directamente con el exterior.
Fábrica
La fábrica en DDD también es un modelo que encarna la idea de encapsulación. La razón por la que se introdujo el patrón de fábrica en DDD es que a veces crear un objeto de dominio es un asunto más complicado, no solo una nueva operación simple. Así como el objeto encapsula la implementación interna (podemos usar el comportamiento del objeto sin conocer la implementación interna del objeto), la fábrica se usa para encapsular el conocimiento necesario para crear un objeto complejo, especialmente cuando se agrega. factory es crear el objeto. Los detalles están ocultos. El cliente pasa algunos parámetros simples a la fábrica, y luego 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 esta tarea, por lo que es necesario introducir este nuevo modelo, fábrica. Cuando una fábrica crea un objeto de dominio complejo, generalmente sabe qué reglas comerciales debe cumplir (primero sabe cómo crear una instancia de un objeto y luego qué operaciones de inicialización se realizan en el objeto. Este conocimiento son los detalles de la creación del objeto). Si se pasa Si los parámetros cumplen con las reglas comerciales para la creación de objetos, el objeto correspondiente se puede crear sin problemas; sin embargo, si el objeto esperado no se puede crear debido a parámetros no válidos u otras razones, se debe lanzar una excepción para garantizar. que no se crea un objeto incorrecto. Por supuesto, no siempre necesitamos crear objetos a través de fábricas. De hecho, en la mayoría de los casos, la creación de objetos de dominio no es demasiado complicada, por lo que solo necesitamos usar el constructor para crear objetos. Los beneficios de ocultar la creación de objetos son obvios. Esto evita que la lógica empresarial de la capa de dominio se filtre a la capa de aplicación y también reduce la carga sobre la capa de aplicación. Simplemente llame a la fábrica de dominios para crear el objeto deseado.
Repositorio
00001. El repositorio está diseñado por esta razón: los objetos en el modelo de dominio no permanecerán activos en la memoria desde que se crean, se conservarán en la base de datos cuando se creen. está inactivo, y luego reconstruiremos el objeto cuando sea necesario; reconstruir el objeto es el proceso de recrear el objeto en función del estado del objeto almacenado en la base de datos, por lo tanto, se puede ver que el objeto reconstruido es un proceso; de tratar con 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 en función de una determinada condición, agregamos objetos a la colección o eliminamos objetos de la colección.
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 un modelo de dominio
00001. Establecer un modelo de dominio preliminar basado en los requisitos e identificar algunos conceptos de dominio obvios y sus correlaciones. Las correlaciones no pueden tener dirección por el momento, pero deben tener relaciones (1:1, 1:N, M:N); el significado de cada concepto de campo y la información principal contenida se pueden describir con palabras con precisión y sin ambigüedades; ;
00002. Analizar las principales funciones de la aplicación de software e identificar las principales clases de la capa de aplicación; esto ayudará 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; /p>
00002.? p>
00003.?Analice más a fondo el modelo de dominio para identificar cuáles son entidades, cuáles son objetos de valor y cuáles son servicios de dominio;
00004.?Analizar la asociación, a través de un análisis más profundo del negocio y Varios principios de diseño de software y compensaciones de rendimiento, aclarando la dirección de la asociación o eliminando algunas asociaciones innecesarias;
00005.? límites de agregación y raíces agregadas Debido a que a menudo se encuentran muchos problemas de selección ambiguos que son difíciles de juzgar claramente durante el proceso de análisis, necesitamos acumular algo de experiencia en análisis para encontrar la raíz agregada correcta;
00006. .? Equipar la raíz agregada con un almacén generalmente consiste en asignar un almacén a un agregado. En este momento, solo necesitamos diseñar la interfaz del almacén;
00007. que el modelo de dominio que diseñamos puede resolver eficazmente las necesidades comerciales
00008 Considere cómo crear entidades de dominio u objetos de valor, ya sea a través de fábricas o directamente a través de constructores
00009. Detenga y refactorice el modelo. Busque áreas en las que crea que hay dudas o cojeras en el modelo. Por ejemplo, ¿algunos objetos deberían obtenerse a través de la navegación asociada o del almacén? ¿Está la agregación diseñada correctamente? Considere el rendimiento del modelo, etc.;
Varios métodos de implementación de la Unidad de Trabajo
00001. ¿Implementación basada en instantáneas, es decir, se extraen objetos de dominio? El objeto de respaldo se guardará primero y luego, al realizar la operación de persistencia, se comparará el estado del último objeto con el estado del objeto de respaldo. Si no son iguales, se considerará que se han realizado modificaciones y. luego se realizará la persistencia. 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 bajo y el proceso de hacer una copia de seguridad del objeto y comparar si el estado del objeto se ha modificado cuando el objeto en sí es muy complejo, suele ser un paso que requiere mucho tiempo y aún es difícil implementar realmente una copia profunda del objeto y determinar si los atributos han sido modificados;
00002.? No se basa en instantáneas, sino en actualizaciones relevantes o nuevas actualizaciones del almacén. Cuando se llama a la interfaz de agregar o eliminar, el almacén notifica a la unidad de trabajo que un objeto tiene añadido, actualizado o eliminado. 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 y no tiene ninguna inclinación hacia el modelo de dominio. También apoya muy bien el 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 Consultar directamente los resultados a través del repositorio de datos requeridos. Sin embargo, la función de consulta proporcionada por el repositorio en la capa de dominio general puede no satisfacer las necesidades de visualización de la interfaz y puede ser necesario llamar a diferentes repositorios varias veces para obtener los datos que de hecho deben mostrarse para este tipo; Consulta, hablaré de ello más adelante. Se puede implementar directamente a través de la arquitectura CQRS.
Es decir, para consultas, podemos completar la consulta directamente a través de algún otro motor de consulta implementado con otra arquitectura técnica, como directamente a través de los parámetros de construcción, sin llamar a nada en la capa de dominio. Use SQL para consultar. cualquier dato que desee mostrar de una o más tablas de 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 varios servicios de consulta para la capa de aplicación, porque los datos que se mostrarán en la interfaz a menudo son una combinación de muchos objetos, que es información conceptual que no es un objeto, como un informe;
Orientado La esencia de los objetos es la división de límites y la encapsulación, que no solo puede cuantificar los cambios en los requisitos y reducir el impacto, porque la división de límites también limitará el alcance del impacto de los errores, OO también es bueno para errores como 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 de. el espacio y el tiempo para traer dolor y desastre al mundo humano están limitados a un cierto rango, y en el mundo del software, si no usas OO y otros métodos para delinear límites, ¿qué tan malo será si haces un cambio? error y localizarlo?
El mundo del software es en realidad similar al mundo real humano. A veces algo sale mal. Cuando analizamos la causa, resulta que es causado por dos factores aparentemente no relacionados. Los antiguos tenían que orar a menudo. a los dioses y budas Nosotros los programadores estamos aquí Cuando nuestro software está en línea y ejecutándose, probablemente estemos orando a Dios para evitar cometer grandes errores. Si nuestro software adopta el empaquetado OO, estaremos más tranquilos. He delineado los límites de antemano, por lo que no habrá errores, se producirán consecuencias graves y ni siquiera habrá errores diabólicos que sean difíciles de rastrear.
Modo de análisis de arquetipos de cuatro colores
Arquetipo de intervalo de momento
Representa algo que sucedió en un momento determinado o dentro de un período de tiempo determinado una actividad. Indicado en rosa, abreviado como MI.
Arquetipo Part-Place-Thing (Arquetipo Part-Place-Thing)
Representa a las personas o cosas que participan en una actividad, y el lugar es el lugar donde se desarrolla la actividad. Utilice verde. La abreviatura es PPT.
Arquetipo de descripción
Representa la descripción esencial de PPT. ¡No es una clasificación PPT! La descripción es una colección de atributos únicos e inmutables extraídos de PPT. Utilice azul, abreviado como DESC.
Por ejemplo, hay una persona llamada Zhang San. Si un extraterrestre te pregunta ¿qué es Zhang San? ¿Qué dirías? Se podría decir que Zhang San es un ser humano, pero los extraterrestres no saben qué es "humano". ¿Qué harás entonces? Dirás: Zhang San es una existencia objetiva compuesta de una cabeza, dos manos, dos pies y un cuerpo. Aunque los extraterrestres todavía no saben qué es un humano en este momento, ya puedo usar este ejemplo para explicarles a todos qué es "Descripción". En este ejemplo, Zhang San es un PPT, y "una existencia objetiva que consta de una cabeza, dos manos, dos pies y un cuerpo" es la descripción de Zhang San, y la cabeza, las manos, los pies y el cuerpo son personas. Una colección de atributos esenciales, inmutables y fundamentales. Pero los humanos somos más inteligentes y somos buenos para resumir y nombrar de forma abstracta. Hemos reemplazado esta descripción con una palabra, que es "humano". Por lo tanto, existe el llamado dicho de que Zhang San es un ser humano.
Arquetipo de Rol
Rol es lo que habitualmente entendemos como “identidad”. Utilice amarillo, abreviado como Rol. ¿Por qué existe el concepto de rol? Porque algunas actividades solo permiten que PPT (participantes) con roles (identidades) específicos participen en la actividad.
Por ejemplo, una persona sólo puede tomar clases (una actividad) si tiene el rol de maestro; una persona puede participar en las elecciones y ser elegida solo si es un ciudadano legal pero algunas actividades no requieren un rol, por ejemplo; , una persona puede dormir sin tener ningún rol (una actividad). Por supuesto, en realidad es un error decir que las personas pueden dormir sin un papel. Porque podemos entenderlo de esta manera: mientras una existencia objetiva tenga un carácter "humano", puede dormir. De hecho, en este momento ya hemos considerado a DESC como un personaje. Por lo tanto, de hecho, el concepto de rol es muy amplio y no puede entenderse en el sentido estricto de "identidad" que generalmente entendemos, porque los "maestros", los "ciudadanos legales" y las "personas" pueden tratarse como roles. Por tanto, cabe decir que cualquier actividad requiere de participantes con determinados roles para participar.
Para resumir el arquetipo de los cuatro colores en una frase, es: qué tipo de persona, organización u objeto participa en una determinada actividad en un determinado momento o dentro de un determinado período de tiempo en un determinado rol . Entre ellos, "algo" es DESC, "persona, organización u objeto" es PPT, "rol" es Rol y "una actividad en un momento determinado o dentro de un período de tiempo determinado" es MI.
Si estudias las cosas anteriores después de aprender DDD, tendrás una comprensión más profunda de DDD, pero creo que DDD es relativamente básico. Si estudiamos sobre la base de que ya entendemos DDD, estas cosas serán más. eficaz y más fácil de dominar.