Introducción al diseño basado en dominios

El famoso experto en modelos Eric Evans publicó su libro más influyente y famoso en 2004: Domain-Driven Design: Tackling Complexity in the Heart of Software. (Diseño impulsado por dominios: la forma de lidiar con la complejidad central del software)

La forma de tratar con software complejo se puede dividir a grandes rasgos en tres métodos, abstracción, dividir y conquistar y conocimiento.

• Abstracción: abstraer problemas complejos en simples
• Dividir y conquistar: divida los problemas complejos en varios problemas pequeños y trátelos por separado.
• Conocimiento: cómo abstraer, dividir y conquistar es más razonable. DDD

Núcleo DDD

• Lenguaje unificado: los desarrolladores / usuarios de software utilizan el mismo lenguaje, es decir, la cognición de un determinado concepto y sustantivo está unificada.
• Orientado al dominio: piense en los problemas en términos de dominios, no de módulos.
• Para lograr estos dos núcleos, se necesita un rol clave, un experto en el dominio. Es responsable del dominio del problema y del dominio de la resolución de problemas. Debe estar familiarizado con los problemas, términos técnicos y relaciones que deben resolverse con el producto que se está desarrollando. En general, la persona más cercana a este rol es el gerente de producto. .

Cómo implementar un lenguaje unificado

• lenguaje común

Un lenguaje común es el lenguaje que puede describir de manera fácil, clara y precisa el significado y las reglas del negocio que se alcanza a través de la comunicación en equipo.

El lenguaje universal es el lenguaje unificado del equipo, independientemente del rol que asumas en el equipo, se utiliza un lenguaje unificado para la comunicación en el ciclo de vida del software del mismo campo.

Los sustantivos en el lenguaje común pueden nombrar objetos de dominio, como usuarios / pedidos. El verbo significa una acción o evento, como un usuario que inició sesión / un pedido pagado, etc.

Sobre esta base, se puede desarrollar un código más legible y los requisitos comerciales se pueden traducir con mayor precisión en el diseño del código.

• Contexto limitado

Se utiliza para determinar el límite del dominio donde se ubica la semántica. Comuníquese en un lenguaje unificado dentro de un límite de dominio unificado.

Se utiliza para encapsular lenguaje común y objetos de dominio, proporcionar un entorno de contexto, garantizar que algunos términos, objetos relacionados con el negocio, etc. (lenguaje universal) en el dominio tengan un significado exacto y evitar juegos de palabras.

El contexto teórico del límite superior es el límite de los microservicios. El contexto limitado es la base principal para el diseño y la división de microservicios.

El reino se puede dividir en múltiples subáreas. Un dominio es equivalente a un dominio de problemas, y el proceso de dividir el dominio en subdominios es el proceso de dividir grandes problemas en pequeños problemas.

• El lenguaje universal define el significado del contexto y el contexto delimitado define el límite del dominio.
• Proceso de implementación: tormenta de eventos> análisis de historias de dominio (usuario)> extracción de objetos de dominio> mapeo de modelos de código y objetos de dominio> realización de código

Que es el campo de los fideos

Ideas de programación

1. POP orientado a procesos: considere los pasos para resolver el problema y realice los pasos para resolver el problema. Aborde los problemas de arriba hacia abajo.
2. POO orientado a objetos: la transacción problemática se divide en varios objetos, y los objetos manejan sus propios asuntos. Orientado al dominio: considere internamente, descubra puntos en común, defina objetos raíz agregados y proporcione servicios externamente. Aborde el problema de forma abstracta.
3. SOA orientada a servicios: a partir del negocio del usuario, las funciones comerciales se consideran servicios poco acoplados. Los microservicios son una extensión orientada a servicios
4. AOP orientado a aspectos: Desde la perspectiva de las clases, funciones comunes abstractas.
5. COP orientado a componentes: componentes EJB

beneficio

1. Debido a que todos usan un conjunto unificado de lenguaje común, el costo de comunicación se reducirá en gran medida y no se considerará como B cuando se analice A.
2. Es bueno para el usuario que usa el producto, ya que puede tener una experiencia unificada y fluida durante la actualización continua del producto. Los usuarios no tienen que quejarse de por qué no se utilizan los datos anteriores después de guardar cada vez que se actualiza el software.
3. Cada equipo puede definir más claramente los conceptos en su propio dominio en su contexto, porque el contexto es el sistema de solución del dominio;
4. Cuando hay una interacción entre contextos delimitados, la consistencia del equipo y el contexto puede garantizar que tengamos un equipo de acoplamiento claro y dependiente aguas arriba y aguas abajo.
5. El desarrollo de productos orientado al dominio nos ayuda a analizar profundamente la lógica interna del producto, enfocarnos en resolver los problemas centrales del producto actual, en lugar de hacer muchos módulos funcionales de manera redundante, en línea, los usuarios no lo usan y los usuarios se quejan de sus necesidades).

Dificultad

1. Muy pocas prácticas de aterrizaje y muy pocas mejores prácticas significan que podemos hacer referencia a menos materiales y correr un mayor riesgo de fracaso del proyecto.
2. Han surgido muchos conceptos y términos nuevos, como raíces agregadas, objetos de valor, arquitectura hexagonal, CQRS (separación de responsabilidades para comandos y consultas), conceptos basados ​​en eventos, etc.
3. Requiere que dediquemos mucho tiempo y energía en el modelado de dominios, y también puede conducir a una situación en la que el esfuerzo no sea proporcional al beneficio. Porque la división del contexto de límites es una prueba del nivel empresarial del arquitecto. Si el modelo de negocio no está bien identificado, el modelo se corromperá en el proceso iterativo.
4. DDD es un conjunto de ideas, un conjunto de diseño de modelado de dominio y un conjunto de uso en un contexto específico. Todos los planes diferentes deben diseñarse en diferentes equipos, y él debe implementarlos de acuerdo con la situación real del equipo para lograr el efecto.

La composición de los equipos modernos de investigación y producción de Internet es generalmente de marketing / operaciones, productos, interacción de la interfaz de usuario, front-end, back-end y pruebas. La división del trabajo de estos roles es separar los diversos procesos de desarrollo y lanzamiento de un producto, y luego cada proceso tiene una persona responsable dedicada, que puede mejorar efectivamente la eficiencia de producción.Este conjunto de procesos es una operación estándar de la línea de ensamblaje.

Las ventajas de esto son indudables y las desventajas también obvias: cada persona solo se enfoca en su propia pieza e ignora el todo.

Herramientas comunes

1. diagrama de flujo
2. Diagrama de tiempo
3. Diagrama de relación entre entidades (modelo ER)
4. Use el diagrama del caso
5. Diagrama UML (modelado de dominio)

Modelo de dominio

El desarrollo de software generalmente se divide en tipo cascada y tipo ágil.

• Cascada: el director del proyecto analiza los requisitos generales de producción y los desarrolladores llevan a cabo el desarrollo.
• Ágil: también requiere mucho análisis, módulos de negocios finos, itera en pequeños pasos y se entrega periódicamente. Ágil es adoptar cambios, que pueden generar una gran cantidad de requisitos o cambios en el modelo de negocio, que traerán consigo considerables costos de mantenimiento.
• DDD: Diseño iterativo con menor granularidad. El modelo de dominio es un portador que puede reflejar con precisión un determinado elemento de conocimiento en el dominio, transformando el conocimiento profesional en un modelo de dominio y diseñando código sobre él.

Modelo de pérdida de sangre

class User { ID de cadena; Nombre de cadena; Edad entera; Getter / Setter .. }

Solo hay un objeto de dominio y el Servicio es responsable de todas las operaciones, incluido el almacenamiento.

Servicio> Entidad de dominio

Modelo de anemia

class UserDao {     @Autowired     JdbcTemplate jdbcTemplate;     public void updateName (nombre de cadena, id de cadena) {         jdbcTemplate.excute ("actualizar usuario u set u.name =? where id =?", nombre, id);     } } class UserService {     @Autowired     UserDao userDao;     void updateName (nombre de cadena, id de cadena) {         userDao.updateName (nombre, id);     } }

La lógica de persistencia se implementa en Dao y el Servicio es responsable del negocio.

Servicio> DAO> Entidad de dominio

Modelo de hiperemia

interfaz UserRepository extiende JpaRepository <Usuario, Cadena> {     // springdata-jpa extiende automáticamente el método save findOne findAll } class UserService {     @Autowoird     UserRepository userRepository;     void updateName (nombre de cadena, id de cadena) {         Usuario usuario = userRepository.findOne (id);         user.setName (nombre);         userRepository.save (usuario);     } }

Sobre la base del modelo de anemia, se agrega una capa de dominio adicional y Dao se coloca en el dominio. El servicio no necesita preocuparse por las operaciones de la base de datos, solo el objeto de dominio en sí. El modo de repositorio está aquí, protegiendo la realización de la base de datos.

Servicio> Dominio> DAO

Modelo de hinchazón

void updateName (nombre de cadena, id de cadena) {     Usuario usuario = nuevo usuario (id);     user.setName (nombre);     user.save (); }

Según el modelo de congestión, el servicio y el dominio se fusionan estrechamente.

Dominio> Dao

Patrones de diseño

Modelo tradicional

• MVC 

Interfaz de usuario> servicio> dao> modelo

Desarrollo basado en datos de diagramas ER, programación orientada a datos, cuando el negocio de servicios aumenta, dao pierde su significado claro, que se llama amnesia causada por anemia

• Modelo DDD

Interfaz de usuario> aplicación> dominio> infraestructura

Interfaz de usuario: pantalla de usuario e instrucciones de usuario

应用层：协调应用活动，不包含业务逻辑，不保留业务对象，只保存任务进度。

领域层：领域信息/业务对象状态，将业务状态和信息委托给基础层

基础层：支撑库，对业务数据持久化，和用户展示库等。

 

概念定义

• 领域：包括问题域和解系统，限界上下文
• 实体：当一个对象由其标识（而不是属性）区分时，这种对象称为实体（Entity）。
• 值对象：当一个对象用于对事务进行描述而没有唯一标识时，它被称作值对象（Value Object）。
• 聚合根：Aggregate(聚合）是一组相关对象的集合，作为一个整体被外界访问，聚合根（Aggregate Root）是这个聚合的根节点。
• 领域服务Services：一些重要的领域行为或操作，可以归类为领域服务。
• 领域事件DE：领域事件是对领域内发生的活动进行的建模。
• 资源库(Repositories)：springdata中的xxxRepository就是基于ddd的充血模型
• 模块(Moudles)：一种控制限界上下文的手段，一般尽用一个模块来表示一个领域量的限界上下文。在工程中开源用包的方式，如com.公司名.组织架构.业务.上下文.*

设计领域模型的一般步骤如下：

1. 根据需求划分出初步的领域和限界上下文，以及上下文之间的关系；
2. 进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象；
3. 对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根；
4. 为聚合根设计仓储，并思考实体或值对象的创建方式；
5. 在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。

扩展

CQRS模式

CQRS — Command Query Responsibility Segregation，命令查询的责任分离模式，将系统中的操作分为两类，即「命令」(Command) 与「查询」(Query)。

• 命令：是对会引起数据发生变化操作的总称，即我们常说的新增，更新，删除这些操作，都是命令。
• 查询：即不会对数据产生变化的操作，只是按照某些条件查找数据。

核心思想

是将这两类不同的操作进行分离，然后在两个独立的「服务」中实现。这里的「服务」一般是指两个独立部署的应用。在某些特殊情况下，也可以部署在同一个应用内的不同接口上。

Command 与 Query 对应的数据源也应该是互相独立的，即更新操作在一个数据源，而查询操作在另一个数据源上。看到这里，你可能想到一个问题，既然数据源进行了分离，如何做到数据之间的同步呢？让我们接着往下看。

CQRS 的架构图

 

有点类似「读写分离」

六边形架构

传统MVC架构分为表现层、业务逻辑层、数据访问层，各层相互依赖，无法单独调整某一层。

六边形架构又称为端口-适配器。六边形架构将系统分为内部（内部六边形）和外部，内部代表了应用的业务逻辑，外部代表应用的驱动逻辑、基础设施或其他应用。内部通过端口和外部系统通信，端口代表了一定协议，以API呈现。一个端口可能对应多个外部系统，不同的外部系统需要使用不同的适配器，适配器负责对协议进行转换。这样就使得应用程序能够以一致的方式被用户、程序、自动化测试、批处理脚本所驱动，并且，可以在与实际运行的设备和数据库相隔离的情况下开发和测试。

 

六边形体系结构基于三个原则和技术：

1. 明确区分应用程序，域和基础设施。

• 应用程序：与外部交互，路由、api、序列化等。
• 域：纯粹的业务逻辑代码。
• 基础设施：需要实现业务逻辑的支持环节，比如数据入库、第三方功能等。

1. 依赖关系从应用程序和基础结构到域：域不依赖外部。
2. 使用端口和适配器隔离边界，

• 端口：域定义端口
• 适配器：链接域的端口与外部交互适配处理。

总结

框架易学，思想难学

如果单从研发角度考虑DDD，开发进行领域建模，然后遵从康威定律，将软件架构设计映射到业务模型中。

康威定律：任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。

参考：

1. 领域驱动设计:软件核心复杂性应对之道，Eric Evans
2. 浅析DDD(领域驱动设计)，https://www.jianshu.com/p/b6ec06d6b594
3. 领域驱动设计在互联网业务开发中的实践，https://tech.meituan.com/2017/12/22/ddd-in-practice.html
4. DDD 中的那些模式 — CQRS，https://zhuanlan.zhihu.com/p/115685384
5. DDD术语-通用语言、限界上下文，https://www.cnblogs.com/junzi2099/p/13682028.html
6. 领域驱动模型（DDD）在美团外卖活动管理业务的应用，https://www.jianshu.com/p/fb319d7674ff
7. 「首席架构师看应用架构」六边形架构：三个原则和一个实现示例，https://baijiahao.baidu.com/s?id=1662240769613294810&wfr=spider&for=pc