Lo que se registra aquí es el contenido del intercambio de aprendizaje, y el artículo se mantiene en Github: studeyang/learrning-share .
¿Cómo entender el Diseño Dirigido por Dominio?
Con el auge de los microservicios, debe haber oído hablar del diseño basado en dominio DDD (diseño basado en dominio), pero si lo considera como un término, parece un poco abstracto. ¿Qué demonios es esto?
No se preocupe, debe haber oído hablar del desarrollo basado en pruebas (TDD, Test-driven development), ¿verdad?
¿Qué es este concepto? Es decir, en el proceso de desarrollo, primero se deben realizar las pruebas, y se recomienda escribir primero el programa de prueba y luego codificar para realizarlo. El desarrollo es el propósito, y las pruebas son auxiliares, por lo que se llama desarrollo basado en pruebas. Debemos dividirlo en tres términos para entenderlo.
Por lo tanto, para el diseño dirigido por el dominio, el diseño es el propósito y el dominio es el auxiliar. Quiero diseñar un software, pero debido a que el negocio es demasiado complicado, el proceso de diseño es difícil. En este momento, use las ideas del dominio para ayudar al diseño.
¿Qué tan pequeño debe ser un microservicio?
Si fueras arquitecto empresarial, ¿qué dificultades encontrarías durante el proceso de diseño? Creo que la primera pregunta a la que te enfrentas es: ¿Qué tan pequeños deben ser los microservicios?
Algunas personas dicen: "Microservicios, ¡cuanto más pequeños, mejor!"
En este momento, la operación y el mantenimiento pueden superarlo. Si los microservicios se dividen demasiado, la complejidad del proyecto será demasiado alta. No solo la operación y el mantenimiento de estos servicios consumirán mano de obra, sino también los microservicios que son demasiado pequeño también ocupará recursos.
¿Existe una teoría o método de diseño adecuado para guiar el diseño de microservicios?
La respuesta es DDD.
DDD es un pensamiento de diseño que se ocupa de dominios complejos, que incluye dos partes, diseño estratégico y diseño táctico. El diseño estratégico es para ayudar a establecer un modelo de dominio comercial, dividir los límites del dominio y establecer un contexto delimitado (el término profesional de DDD, que se explicará a continuación).
El diseño táctico comienza desde una perspectiva técnica, se centra en la realización técnica del modelo de dominio y completa el desarrollo y la implementación del software, incluido el diseño y la implementación del modelo de arquitectura de código de microservicio.
¿Cómo guía la idea de DDD la división de microservicios? Se puede dividir en tres pasos:
El primer paso es enumerar escenarios comerciales y buscar objetos de entidad de dominio.
En el segundo paso, de acuerdo con la asociación comercial entre entidades de dominio, las entidades relacionadas se combinan para formar una agregación. Pertenecen al mismo microservicio.
El tercer paso es definir múltiples agregados en un contexto acotado de acuerdo con el límite semántico para formar un modelo de dominio. Esta capa de límite es el límite de los microservicios.
Pensamientos en el campo DDD
Al estudiar problemas de dominios complejos, DDD subdividirá el dominio comercial de acuerdo con ciertas reglas, lo cual es similar al método de investigación de las ciencias naturales.
Cuando las personas se encuentran con problemas complejos en la investigación de las ciencias naturales, la práctica habitual es subdividir el problema de acuerdo con ciertas reglas y luego realizar una investigación en profundidad sobre los subcampos del problema subdivididos uno por uno. Se ha establecido un sistema completo de conocimiento en todos los campos.
Por ejemplo: Supongamos que queremos estudiar un melocotonero. Según los diferentes órganos, se divide en órganos vegetativos y órganos reproductivos, y los órganos vegetativos se subdividen en hojas, tallos y raíces, y los órganos reproductivos se dividen en flores, frutos y semillas.
Los órganos se subdividen a su vez en tejidos. Para subdividir aún más el tejido, subdivida el tejido en células. La célula es la unidad más pequeña que queremos estudiar. Las paredes de las celdas entre las celdas definen los límites de las celdas y también los límites mínimos del estudio.
subregión
El melocotonero se subdivide en seis subcampos: raíz, tallo, hoja, flor, fruto y semilla. Los subdominios se dividen según el grado de importancia y se dividen en dominios centrales, dominios generales y dominios de soporte.
El subdominio que determina la competitividad central del producto y la empresa es el dominio central; no hay muchas apelaciones personalizadas, y el dominio general es utilizado por múltiples subdominios al mismo tiempo; no contiene las funciones que determina la competitividad central del producto y la empresa, ni contiene un subdominio general de la función, que es el dominio de apoyo.
Cabe señalar que el dominio central debe determinarse de acuerdo con la estrategia de desarrollo de la empresa y la situación real del negocio.
Por ejemplo, si el dueño de este árbol de durazno es un jardinero, entonces le preocupan las flores de durazno en plena floración y el jardín lleno de primavera, por lo que las flores son el dominio central. Si el propietario de este durazno es un productor de frutas, entonces le preocupa la calidad y el rendimiento de los duraznos, por lo que la fruta es el dominio principal.
límites superior e inferior
Sabemos que un lenguaje tiene su entorno semántico, para evitar la ambigüedad del mismo concepto o semántica en diferentes contextos, DDD propone el concepto de "contexto acotado" en el diseño estratégico, que se utiliza para determinar el límite del dominio donde se encuentra el se ubica la semántica.
Por ejemplo: las dos cuentas en la figura a continuación, no podemos distinguirlas solo por sus nombres, y solo podemos ver la diferencia entre ellas a través del contexto delimitado en el que se encuentran.
Para otro ejemplo, las mercancías en el campo del comercio electrónico tienen diferentes términos en diferentes etapas: son mercancías en la etapa de venta, pero se convierten en mercancías en la etapa de transporte. Lo mismo, debido a diferentes campos de negocios, le da a estos términos diferentes significados y límites de responsabilidad.
Un contexto delimitado se puede dividir en un microservicio, y este límite hace que un concepto no sea ambiguo dentro de este límite.
entidad
En resumen, hay cuatro formas.
Primero, la forma de negocio de la entidad: En el diseño estratégico, la entidad en el modelo de dominio es portadora de múltiples atributos, operaciones o comportamientos.
En segundo lugar, la forma de código de la entidad: en el modelo de código, la forma de la entidad es la clase de entidad, que contiene los atributos y métodos de la entidad, así como la lógica empresarial central.
DDD enfatiza el "diseño como código". Para el caso de uso comercial de la "vacuna contra la gripe", cuando el equipo analiza el modelo de negocios, dicen: "Las enfermeras les dan a los pacientes una dosis estándar de la vacuna contra la gripe".
El código tradicional se ve así:
public void shot() {
patient.setShotType(ShotTypes.TYPE_FLU);
patient.setDose(dose);
patient.setNurse(nurse);
}
La representación en código del pensamiento DDD es:
public void shot() {
Vaccine vaccine = vaccines.standardAdultFluDose();
nurse.administerFluVaccine(patient, vaccine);
}
Obviamente, el segundo tipo de código es mucho más fácil de entender.
En tercer lugar, la forma operativa de la entidad: la entidad existe en forma de DO (objeto de dominio), y cada objeto de entidad tiene una identificación única. Podemos modificar un objeto de entidad varias veces y los datos modificados pueden ser bastante diferentes de los datos originales. Sin embargo, dado que tienen la misma identificación, siguen siendo la misma entidad.
En cuarto lugar, la forma de base de datos de la entidad: cuando el modelo de dominio se asigna al modelo de datos, la entidad y el objeto persistente son uno a uno en la mayoría de los casos.
objeto de valor
El objeto de valor es un objeto básico en el modelo de dominio DDD.Al igual que la entidad, contiene varios atributos y, junto con la entidad, forma una agregación.
- La forma comercial del objeto de valor.
En esencia, las entidades son objetos comerciales tangibles que se pueden ver y tocar. Las entidades tienen atributos comerciales, comportamientos comerciales y lógica comercial. Un objeto de valor es solo una colección de propiedades.
- La forma de código del objeto de valor.
public class Person {
private Integer id;
private String name;
private Address address;
}
private class Address {
private String province;
private String city;
private String county;
}
Echemos un vistazo al código anterior. La entidad Persona tiene varios objetos de valor de atributo único, como id, nombre y otros atributos; también contiene varios objetos de valor de atributo, como dirección de dirección.
- La forma operativa del objeto de valor.
Los atributos comerciales y los comportamientos comerciales de los objetos DO después de la instanciación de la entidad son muy ricos, pero los objetos instanciados por objetos de valor son relativamente simples.
- La forma de la base de datos del objeto de valor.
En el modelado de dominios, podemos diseñar algunos objetos como objetos de valor, conservando el significado comercial de los objetos, mientras reducimos el número de entidades; en el modelado de datos, podemos incrustar objetos de valor en entidades, reduciendo el número de tablas de entidades, simplificando el diseño de la base de datos .
En algunos escenarios, una entidad hará referencia a una dirección, que solo asume la función de describir la entidad, y su valor solo se puede reemplazar como un todo. En este momento, puede diseñar la dirección como un objeto de valor, como la dirección de entrega En algunos escenarios comerciales, la dirección se modificará con frecuencia y la dirección existe como un objeto independiente. En este momento, debe diseñarse como una entidad, como el mantenimiento de la información de la dirección en las divisiones administrativas.
Agregados y Raíces de Agregados
Por ejemplo. La sociedad está formada por individuos, cada uno de nosotros es un individuo. Con el desarrollo de la sociedad han ido surgiendo paulatinamente asociaciones, instituciones, departamentos y otras organizaciones.También hemos pasado de individuos a miembros de la organización.En la organización, todos trabajan juntos para lograr mayores metas y ejercer mayor fuerza.
Las entidades y los objetos de valor en el modelo de dominio son como individuos, y la organización que permite que las entidades y los objetos de valor trabajen juntos es la agregación, que se utiliza para garantizar que estos objetos de dominio puedan garantizar la coherencia de los datos al implementar una lógica comercial común.
Si el agregado se compara con una organización, entonces la raíz del agregado es la persona a cargo de la organización. La raíz agregada también se denomina entidad raíz, que no solo es la entidad, sino también el administrador del agregado.
Entre agregados, las referencias se asocian a través del ID de raíz del agregado. Si necesita acceder a entidades en otros agregados, primero debe acceder a la raíz del agregado y luego navegar a las entidades internas del agregado. Los objetos externos no pueden acceder directamente a las entidades del agregado. .
Finalmente, utilizo la siguiente figura para resumir el dominio, el contexto delimitado, la entidad, el objeto de valor, la agregación y la raíz de agregación.
la cubierta
Artículos relacionados
Quizás también te interese el siguiente artículo.