antecedentes
- Recientemente, la empresa ha comenzado a implementar DDD ( Domain Driven Design ). El modelo de desarrollo orientado a objetos basado en el modelo de congestión es una de las características de DDD. En el desarrollo normal, todos usamos la arquitectura MVC, que es un estilo de desarrollo orientado a procesos basado en el modelo de anemia. Los estudiantes preguntarán, ¿cuáles son los modelos de anemia y los modelos de congestión?
Modelo de anemia y modelo de congestión
Introducción
Modelo de anemia :
- Defina el valor de atributo simple del objeto, no hay un método de lógica comercial (comprensión personal), no se encuentra una explicación oficial
Modelo de hiperemia
- El modelo de congestión significa que cuando definimos atributos, también definimos métodos. Nuestros atributos se pueden obtener directamente de alguna manera. Luego podemos incrustar métodos en el objeto para crear directamente un objeto con valores de atributo. En otras palabras, este objeto ya no nos obliga a realizar más operaciones, que también componen la encapsulación de una de las tres características principales de la POO (comprensión personal)
Acerca de la relación entre DDD y modelo de hiperemia
Cuando solemos hacer desarrollo web, definimos DTO, definimos el modelo de base de datos, BO, etc., realizamos el método get set en él, luego operamos el objeto Bo a través del servicio y finalmente persistimos la base de datos y la transmisión DTO a través del atributo copy. Pero si se trata de un modelo congestivo, no es necesario realizar la asignación de atributos en el servicio, sino que al crear este objeto, realice operaciones comerciales y asigne sus valores de atributo. Esta es la idea de DDD, y este objeto es la Entidad o valor definido por DDD. El servicio es domianService, que se compone de múltiples Entidades y valores para construir el modelo de dominio final.
La siguiente figura es la comprensión del propio autor de DDD, y espero que pueda ayudar a todos a comprender:
Volviendo al tema o mire el modelo de congestión y el
modelo de anemia ¿Cuál es la ventaja del modelo de congestión en tantos pensamientos de DDD? ¿Qué escenarios son aplicables? ¿Y todos estamos usando el modelo de anemia, pero no tenemos problemas en nuestro desarrollo habitual?
¿Por qué todos usan el modelo de anemia?
- Utilizando el modelo de desarrollo tradicional del modelo de anemia, los datos y la lógica empresarial están completamente separados, y las propiedades del objeto se pueden cambiar a través del método get set, y las propiedades del objeto se pueden modificar a voluntad. Esto también viola las características de encapsulación de las tres características principales de OOP como se mencionó anteriormente. Este método de programación es también un método de programación orientado a procesos El método de programación orientado a procesos se ajusta a la lógica del cerebro humano y no necesita utilizar demasiados patrones de diseño ni diseños excesivos. También hay una frase muy irresponsable que la gente suele decir en el desarrollo: "¿Qué tan conveniente es?", He estado apilando código, que es completamente diferente de la escalabilidad futura.Es decir, el método de programación basado en el modelo de anemia es la programación orientada a procesos, la lógica del pensamiento humano es muy consistente y el proceso de programación también es muy conveniente, por lo que todos están dispuestos a aceptar este método de programación.
- En resumen:
- El diseño del modelo de hiperemia es más difícil que el modelo de anemia
- Se ha convertido en un hábito que todo el mundo utilice sistemáticamente la programación orientada a procesos basada en el modelo de anemia, y es difícil cambiar el pensamiento
- También hay una actitud irresponsable hacia el código. (Este es un problema común de la mayoría de los programadores)
¿El modelo de congestión es adecuado para todos los escenarios?
- Usar el modelo de congestión es usar el modelo de desarrollo de DDD basado en el modelo de congestión. Lo anterior ha enfatizado repetidamente que el modelo de congestión también es un modelo de definición complicado y difícil de diseñar. La cantidad de desarrollo de código puede ser mayor que otros modelos. La razón principal es que el diseño es difícil. Es decir, si diseñamos una lógica de negocios muy simple, ¿todavía necesitamos ideas de diseño tan complejas? Y este negocio no será complicado en iteraciones posteriores, así que personalmente creo que usaremos nuestras ideas de programación orientadas a procesos basadas en el modelo de anemia. Por qué complicar las cosas simples. De repente pensé en un párrafo que dije al mismo tiempo:
- 普通程序员写hello word 直接print
- 高级程序员写hello word 各种设计模式各种可拓展最后输出hello word
- 技术专家写hello word ，直接打印hello word
- Por supuesto, estamos trabajando en un escenario empresarial complejo, por lo que necesitamos desarrollar un modelo de desarrollo DDD (modelo dirigido por dominios) basado en el modelo de congestión. De hecho, el modelo de desarrollo de DDD es seguir completamente las tres características principales de OOP (o las cuatro características principales, encapsulación, herencia, polimorfismo, (abstracción)). Si se trata de la programación orientada al proceso del modelo de anemia, entonces el resultado final es la práctica puntual Las líneas, desde las líneas hasta las redes, están densamente empaquetadas y no se pueden mantener. Por tanto, se desarrolla una lógica empresarial compleja basada en el modelo de congestión. Pero también está el problema de la expansión de clases, una clase tiene mucho código. Esto aún se puede resolver, es decir, mediante patrones de diseño y segmentación de la lógica empresarial.
para resumir
- Explicación simple del modelo de anemia y el modelo de congestión
- Y la relación entre el modelo de desarrollo DDD y la programación orientada a procesos y los modelos de congestión y anemia
- Comparar el paradigma de programación orientada a procesos de la capa MVC basado en el modelo de anemia y el paradigma de programación orientada a objetos basado en el modelo de congestión
- Los dos modelos son adecuados para ese escenario
referencia
- https://time.geekbang.org/column/article/169600 La belleza de los patrones de diseño
- https://zh.wikipedia.org/wiki/%E5%8F%8D%E9%9D%A2%E6%A8%A1%E5%BC%8F Modo negativo
- http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html Teoría básica de DDD