Una breve discusión sobre algunos principios y patrones de diseño en enlaces de transacciones

[Vista previa de la conferencia Yuan Chuang] Día del Programador 1024 (dos días antes), reúnase en la oficina de Open Source China, ¡hablemos de IA! >>>

secuencia

Recientemente leí algunos libros que había leído brevemente antes, uno de los cuales era "Patrones de arquitectura de aplicaciones empresariales". Quería escribir algunas notas de lectura, pero el tiempo de escritura fue en 2003, que fue hace mucho tiempo. Tal vez el sistema La estructura también ha cambiado drásticamente: se siente muy antigua cuando se extrae y la resonancia no es tan buena. Sin embargo, la paz interior que sentí al leerlo todavía era muy nostálgica. Mirando hacia atrás, también he estudiado principios de diseño, patrones, etc. antes, pero principalmente solo hablé de mis sentimientos. Si desea obtener la paz interior, aún debe consultar la lógica del libro y conectarla con algunos conocimientos en el trabajo diario. Entonces, hablemos brevemente basándonos en estos principios y algunos modelos.

Criterios de diseño

principio de responsabilidad única

definición:

El principio de responsabilidad única (SRP: principio de responsabilidad única), también conocido como principio de función única, es uno de los cinco principios básicos de la orientación a objetos (SOLID). Estipula que una clase debe tener solo un motivo de cambio.

Caso: Diferentes actividades comerciales tienen diferentes entradas de servicio. Ya sea un sistema de cumplimiento o un sistema de reembolso inverso, existen muchos BPM de procesos comerciales. La ventaja de esto es que los escenarios se pueden dividir mejor: el límite actual, la definición de error, el diseño del proceso, las pruebas de regresión, etc. de la interfaz en diferentes escenarios se pueden desarrollar de forma independiente y el área de impacto es relativamente segura. Si utiliza un servicio general con muchos subservicios enrutados en él, aunque parece que puede realizar algunas operaciones comunes, habrá más restricciones y restricciones mutuas, y los aspectos también pueden resolver algunos problemas comunes, por lo que no hay una necesidad particular. . Extensión: Lo que merece un debate más profundo es que, aunque es más fácil llegar a un consenso sobre el aislamiento de la capa de entrada, ¿se permite compartir procesos, nodos de proceso, capacidades, extensiones, etc. en diferentes escenarios más abajo? En la operación real, a menudo depende de la diferencia en capacidades, la complejidad del escenario y la consideración integral de los costos de desarrollo y mantenimiento. Los diferentes estilos de sistemas no son lo mismo:

El sistema de cumplimiento se resolverá de acuerdo con el nivel de capacidades. Dentro de una capacidad, se deben considerar múltiples escenarios. Por ejemplo: al extender el punto de pago, puede provenir de confirmar el recibo, puede provenir de la devolución y el pago, o puede provenir de la pérdida del depósito;
La expansión del sistema de reembolso inverso será lo más independiente posible según las actividades comerciales, como la personalización del tiempo de espera de los reembolsos, los compradores que solicitan reembolsos, los vendedores que aceptan reembolsos, los compradores que devuelven productos y otras actividades comerciales diferentes tienen sus propios puntos de expansión.

Aunque la influencia de la independencia se reducirá, al modificar algunas escenas pueden perderse por demasiada independencia, todo tiene dos caras. Afortunadamente, cuando tomamos decisiones, los escenarios a los que nos enfrentamos suelen ser específicos y contables.

Comprender el principio de responsabilidad única

principio de apertura y cierre

definición:

El principio abierto-cerrado, en el campo de la programación orientada a objetos, estipula que "los objetos (clases, módulos, funciones, etc.) en el software deben estar abiertos a la extensión, pero cerrados a la modificación", lo que significa que una entidad puede para ser modificado en diferentes momentos.Cambia su comportamiento sin cambiar su código fuente.

Caso: ya sea la iteración del marco extendido TMF o la propuesta posterior del sistema de anillo en estrella, un propósito importante es resolver el "aislamiento del negocio y la plataforma", que también es una encarnación importante del principio de apertura y cierre. La lógica central debe ser controlada por personas que estén familiarizadas con la plataforma y debe ser lo más versátil posible con menos modificaciones; la lógica de extensión debe ser entendida por los desarrolladores de negocios y debe ser lo más flexible posible y fácil de ajustar. Mirando dentro del sistema, en realidad hay muchas extensiones de capacidades de dominio. Por ejemplo, al pagar, puede conectarse directamente a Alipay o puede vincularse a canales que no son de Alipay, como WeChat, a través del sistema de pago. Esta expansión también es una manifestación del principio de apertura y cierre, pero está más cerca del proceso central y tiene un mayor impacto. Mirando fuera de la extensión, incluso dentro de complementos como paquetes de aplicaciones comerciales y paquetes de productos, es posible que aún sirvan para múltiples industrias y escenarios, y puede haber muchos redireccionamientos y extensiones. Por ejemplo: Taoxi tiene que servir a muchas industrias, como ropa, electrodomésticos, belleza, etc. Las diferentes personalizaciones comerciales también son diferentes y, a menudo, utilizan algunas estrategias y modelos de expansión de la cadena de responsabilidad. Se puede ver que cada nivel puede diseñar su propio mecanismo de expansión. Extensión: En cuanto al nivel de expansión del anillo estelar, hay varias cuestiones que se pueden considerar más a fondo. 1. Mecanismo de aislamiento empresarial Para las partes cambiantes aisladas, en realidad tenemos más expectativas: esperamos que diferentes empresas y mantenedores puedan aislarse entre sí. Aunque en el sistema Starlink el concepto de identidad empresarial se utiliza para el aislamiento, esto es solo desde una perspectiva técnica. Los conflictos de escenarios se trasladan al nivel de análisis tanto como sea posible, lo que reduce la presión de la ejecución posterior y no es muy flexible cuando usado. Por ejemplo: si no existe una "identidad comercial" para realizar un pedido al enumerar productos, los productos enumerados se identificarán según las etiquetas del producto, etc., y abarcarán múltiples "negocios". Afortunadamente, existen soluciones técnicamente de "paquetes de productos" que pueden superponer servicios y lograr la reutilización lógica, pero a menudo ocurren escenarios de "superposición faltante". Sin embargo, si no se proporciona el concepto de identidad empresarial y el juicio se basa en el escenario de la solicitud, entonces el impacto y la expresión estarán llenos de incertidumbre y será difícil determinar el conflicto entre "quién" y "quién" cuando resolviendo el conflicto. 2. El límite entre negocio y plataforma . A menudo nos referimos al dominio básico, de hecho, se puede considerar como el dominio básico +, porque además de las capacidades y extensiones del dominio, también incluimos procesos de negocios, capacidades comerciales e implementación básica. , plataforma compartida, paquetes comunes, SDK de desarrollo, etc. Se considera básico y requiere la participación del personal de la plataforma. Sin embargo hay algunas excepciones:

En la expansión del dominio, se proporcionan capacidades para un negocio especial (la lógica de este negocio es relativamente completa e independiente) sin llegar al punto de expansión. Habrá situaciones de cooperación especiales que crecerán en el paquete jar de la plataforma, pero las reglas de evolución están básicamente determinadas por el negocio y el desarrollo requiere la intervención de la plataforma;
En un sistema implementado de forma independiente, la base del código se bifurca y evoluciona de forma independiente. En este momento, todo el nivel se definirá como "negocios";
Las capacidades comerciales se consideran capacidades de plataforma y también se integrarán en el paquete sar de plataforma, pero las capacidades comerciales, como los impuestos y las importaciones, son básicamente mantenimiento comercial internacional y difícilmente se puede decir que sean lógicas de plataforma.

A juzgar por estos ejemplos, los límites entre negocio y plataforma han ido más allá de niveles específicos de definición y ya no son tan absolutos. El núcleo todavía sigue la dirección de “integración de derechos y responsabilidades”.

Comprender el principio de apertura y cierre.

Principio de sustitución de Richter

definición:

Principio de sustitución de Liskov LSP es uno de los principios básicos del diseño orientado a objetos. El principio de sustitución de Liskov dice que dondequiera que pueda aparecer una clase base, definitivamente puede aparecer una subclase. LSP es la piedra angular de la herencia y la reutilización. Solo cuando la clase derivada puede reemplazar a la clase base y la función de la unidad de software no se ve afectada, la clase base se puede reutilizar verdaderamente y la clase derivada también puede agregar nuevos comportamientos sobre la base. de la clase base. .

Caso: Ideas alternativas, a menudo usamos:

Al personalizar los puntos de extensión, no nos importan los resultados devueltos por el paquete comercial o el paquete de producto del escenario, solo los resultados personalizados.
Al cambiar de base de datos, no nos importa a qué servicio de datos vamos, solo nos importan los resultados devueltos;
Al llamar al sistema de pago externo, no nos importa si usamos Alipay o WeChat, solo nos importa el resultado del pago;
Al consultar pedidos, no nos importa si utilizamos la base de datos de pedidos o servicios externos (como la evaluación), solo nos importan los resultados de la consulta;
.......

El principio de reemplazabilidad nos permite programar hacia la abstracción; si el reemplazo puede ser lo suficientemente fluido depende de si nuestra abstracción es razonable. Extensión: aunque podemos abstraer y lograr un reemplazo personalizable, de hecho, a menudo es difícil lograrlo sin sentido:

Las garantías de servicio pueden ser diferentes: por ejemplo, se consulta la base de datos de pedidos para el pago y el envío, y se consulta la interfaz de evaluación para la evaluación. El nivel de garantía y las capacidades de la interfaz pueden ser inconsistentes. Se necesitan garantías de estabilidad adicionales.
Las capacidades de implementación pueden ser inconsistentes: después de 3 meses, el pedido se ingresará en la base de datos del historial. Aunque el nivel de consulta se puede adaptar para que los consumidores no lo sepan, las operaciones posteriores de los consumidores estarán restringidas porque cuando se realice el cambio hecho, las capacidades de ambas partes son diferentes. Algunos botones se degradarán después de ingresar a la biblioteca de historial.
El acuerdo puede ser inconsistente: por ejemplo, al reemplazar el sistema de pago, Alipay tiene una transacción garantizada, por lo que es más rápido y conveniente reembolsar el dinero durante la venta. Sin embargo, debido a la influencia de la custodia y las estrategias posteriores del fondo, los reembolsos pueden no será oportuno debido al canal de inicio de sesión de WeChat. Los códigos de error en ambos lados también son diferentes.
.......

Comprender el principio de sustitución de Richter

Ley de Demeter

definición:

La Ley de Demeter se puede expresar simplemente como: habla sólo con tus amigos inmediatos. Para OOD, se interpreta de la siguiente manera: una entidad de software debe interactuar con otras entidades lo menos posible. Cada unidad de software tiene un conocimiento mínimo de otras unidades y está limitado a aquellas unidades de software que están estrechamente relacionadas con su propia unidad.

Caso: El proceso de ejecución de las actividades empresariales es un proceso de coordinación de operaciones de datos, al final todos llegan a un acuerdo y envían mensajes a la base de datos. En este proceso, para coordinar la colaboración en varios campos, existe una capa de coordinación compuesta por un conjunto de procesos básicos y nodos correspondientes, el coordinador más típico en esta capa es el contexto (conceptos como Solicitud, Resultado, Contexto, etc. ). Los datos se obtienen del contexto y, si se van a pasar a nodos posteriores, es necesario rellenar el contexto, lo que se denomina reciclaje. Desde una perspectiva más amplia, el sistema de entrada también desempeña el papel de coordinador. Por ejemplo, el sistema de realización de pedidos llamará al sistema de productos básicos, al sistema de inventario, al sistema de marketing, al sistema de capital, al sistema de cumplimiento, etc., para recopilar y transmitir datos. Los sistemas rara vez se llaman entre sí directamente. Dichos coordinadores a menudo realizan operaciones de llamada y conversión, pero debido a esta capa de conversión, también tienen comprensión y control:

El modelo se puede simplificar, reduciendo la transferencia de datos y las conversiones múltiples en el enlace;
Se puede controlar el modo de solo lectura para evitar manipulaciones inesperadas posteriores;
Puede ahorrar rendimiento, diseñar carga diferida y otros modos, y obtenerlo cuando sea necesario;
......

Extensión: debido a que el coordinador necesita llevar información sobre cada participante, se volverá cada vez más pesada a medida que aumente el número de participantes. Y debido a que algunos sistemas tienen muchas capas, también serán torturados por capas encubiertas. Cada vez que se agrega un nuevo dato, es necesario agregarlo nuevamente. Así, poco a poco, todo el mundo empezó a utilizar modelos compartidos, que contenían datos relativamente originales. Detrás de este resultado surge otra idea: si cada participante proporciona un área fija para obtener datos sin procesar y juega con el centro de datos, ¿puede pasar por alto al coordinador y transmitirlos capa por capa? Y los centros de datos también deberían saber cómo gestionar mejor sus propios datos. Si solo convierte entre niveles del sistema, entonces será mucho más conveniente, pero si existe alguna lógica de proceso oscura entre sus sistemas que pueda procesar estos datos, entonces está más allá del alcance del centro de datos. Además, si tiene un diseño de raíz agregado donde algunas partes son un monolito, también es difícil operar la coherencia entre centros de datos dispersos. Por último, y lo que es más importante, si el propio coordinador está encargado de la coordinación, entonces debe ser "muy conocido". Para el desarrollo también es muy importante si el contexto es más fácil de encontrar o si los centros dispersos son más fáciles de encontrar. El enfoque descentralizado requiere ciertos protocolos.

Ley de Demeter

Principio de aislamiento de interfaz

definición:

Un cliente no debe depender de interfaces que no necesita. La dependencia de una clase de otra clase debe basarse en la interfaz más pequeña. Es mejor utilizar múltiples interfaces especializadas que una única interfaz general. La dependencia de una clase de otra clase debe basarse en la interfaz más pequeña.

Caso: Los casos comunes de aislamiento de interfaz incluyen:

Aislado por capacidades de lectura y escritura: un conjunto de interfaces para leer datos y otro conjunto para operaciones de escritura.
Aislamiento por función operativa: un conjunto de interfaces para que operen los compradores, otro para que operen los vendedores y otro para que operen los camareros.
Aislar por tipo de página: un conjunto para PC, un conjunto para H5 y un conjunto para cliente.
Aislado por protocolo de componente: un conjunto para Ultron, un conjunto para Astore y un conjunto para DTO.
........

Al ver estos escenarios, naturalmente pensamos en el aislamiento y lo más probable es que el código en sí esté en diferentes módulos. El aislamiento de interfaces no es solo un método de declaración:

Para el cliente, también se pueden reducir las dependencias (aunque cada sistema a menudo solo tiene un cliente grande) y se pueden eliminar algunas dependencias innecesarias;
Para el servidor, también puede desarrollarse mejor de forma independiente y evitar el acoplamiento, y lo compartido y lo común también se pueden abstraer para su reutilización.

Extensión: En el sistema de gestión de pedidos existe una interfaz llamada doOp, que define el funcionamiento del botón, a través de los diferentes códigos de operación pasados se puede "recordar el envío", "cancelar el pedido", "eliminar el pedido". y "ampliar la colección de bienes" y otras operaciones diversas. El trasfondo de esto es que puede haber cientos de botones de pedido. Definir la interfaz no es solo una cuestión del servidor. También debe solicitar la interfaz de paquete inalámbrico mtop, y el cliente también debe heredarla. Para poder reutilizarla la ruta al cliente tanto como sea posible, Proporciona una interfaz relativamente común. Aquí puede ver que el principio de independencia de la interfaz no es absoluto y está relacionado con el número de abstracciones y el grado de similitud entre ellas. Además, el ejemplo del botón anterior no está "absolutamente no aislado", es solo la reutilización de la capa de entrada, y luego será estrictamente ortogonal al código del botón y se enrutará a diferentes estrategias de procesamiento según el código del botón. .

Comprender el principio de aislamiento de interfaz

principio de inversión de dependencia

definición:

El principio de inversión de dependencia significa que los programas deben depender de interfaces abstractas y no de implementaciones específicas. En pocas palabras, requiere programar la abstracción y no la implementación, reduciendo así el acoplamiento entre el cliente y el módulo de implementación.

Caso: si cree que el servicio básico no cambiará en el corto plazo y no hay múltiples conjuntos de implementaciones, a menudo confiará directamente en la lógica de "la capa superior depende de la capa inferior" en el enlace de llamada. lo cual será muy simple y eficiente. Por ejemplo, el servicio de consulta de pedidos en el sistema de gestión de pedidos se considera Repo y, como servicio subyacente, la instancia se llama directamente en el dominio. Si cree que el servicio es externo y no está sujeto a su propio control, y desea aislar los cambios y conservar la capacidad de actualizar la interfaz, a menudo incluirá otra capa de interfaces. Existe un concepto de puerta de enlace en el sistema de pedidos y cumplimiento. Se ha vuelto dependiente de interfaces de servicios abstractos y no conoce instancias de implementación específicas. Agregar una capa de interfaz abstracta para el desacoplamiento mantendrá mejores capacidades de acoplamiento flexible, porque la interfaz es un contrato abstracto y ambas partes pueden desarrollarse de forma independiente, pero también traerá costos de gestión, lo cual es un juicio y una compensación. Extensión: Aunque conceptualmente este nivel es muy bueno, todavía existen algunos costos para hacerlo bien:

Módulo de empaquetado: supongamos que en el proceso de que A dependa de B, se introduce C abstracto. Dicha capa de abstracción, debido a que no tiene nada que ver con A y B, debería ser un paquete jar y una biblioteca de códigos separados. Sin embargo, a menudo debido a la dificultad de crear una nueva biblioteca, se alojará en un submódulo de A o B. Al empaquetar, es necesario escribirlo por separado, lo cual es bastante incómodo.
Desafíos de objetos complejos: las interfaces orientadas a lo abstracto significan más conversos. En los sistemas comunes, esto puede ser relativamente fácil, pero en el contexto del comercio de diseños de objetos complejos, será un proceso doloroso. Lo que es aún más lamentable es que los objetos de dominio del sistema comercial y el modelo de base de datos son un mapeo lógico. Después de superponer estas capas, es difícil encontrar cómo se obtienen los datos.

Por lo tanto, a veces vamos en la dirección opuesta y elegimos el modelo estrechamente acoplado. En un sistema complejo, muchas veces nos sentimos así: la simplicidad, la pureza y el acoplamiento estrecho son el rayo de luz, porque poco a poco se puede encontrar el Código correspondiente, en lugar de punto-punto-punto-punto-punto-punto-punto, te pierdes. Cuando digo esto, no estoy jugando al abogado del diablo. Espero que podamos mirar el problema dialécticamente y combinarlo con el escenario específico. Sólo cuando nos rendimos podemos ganar, y donde ganamos debemos perder.

principio de inversión de dependencia

Patrones de diseño

A continuación seleccionamos algunos de los 23 patrones de diseño para su introducción.

Plantilla

El método de plantilla significa descomponer de forma abstracta un proceso de ejecución y completar una lógica principal estándar y una expansión a través de métodos de esqueleto y extensión.

Es más apropiado hacer una analogía con el diseño de la plataforma y las capacidades de expansión en el enlace de transacciones. La plantilla básica es la disposición de todo el proceso y los nodos correspondientes, y el área escalable son las distintas áreas de personalización empresarial. Esto forma una mejor integración de la plataforma y el negocio.

Cadena de Responsabilidad

La cadena de responsabilidad significa que los procesadores en la cola ejecutan las solicitudes una por una hasta que se encuentra uno que esté dispuesto a ejecutar.

La expansión de la capacidad comercial y la expansión del dominio atravesarán los complementos implementados al reciclar los resultados y combinarán las reglas de reciclaje para realizar disyuntores oportunos. Esto es similar a la lógica de la cadena de responsabilidad. Tome como ejemplo "si se debe omitir la notificación de pago" al confirmar la recepción de bienes y realizar el pago. El motor de ejecución de TMF recorrerá la implementación de paquetes de productos y paquetes de aplicaciones. Cuando encuentre el primer resultado que devuelva verdadero (omitir), lo hará detener la ejecución. Devuelve verdadero en general.

Estrategia

Estrategia significa que existen diferentes algoritmos para completar una tarea y se pueden realizar cambios relevantes.

En el reembolso inverso, se deben admitir diferentes enlaces de reembolso: algunos deben ser transacciones garantizadas, otros deben ser enlaces de depósito, algunos deben ser pagos de WeChat y otros deben devolver tarjetas y activos. Para admitir múltiples estrategias de retiro, se adopta el modo de estrategia: se pueden personalizar varias estrategias de fondos a través de puntos de extensión y se pueden ejecutar una o varias estrategias de fondos al mismo tiempo.

Observador

El patrón de observador significa que completamos el mecanismo de colaboración de notificación de cambios a través de un diseño colaborativo como el registro y la devolución de llamada.

En el comercio, el modo de observador dentro del sistema es raro. Sin embargo, todavía existen muchos modos de observación basados en mensajes entre sistemas. Un retiro típico de 0 inversos: al monitorear el mensaje creado por el reembolso y realizar una llamada de consentimiento, se realiza la función de consentimiento rápido del retiro de 0. A través del método de notificación asincrónica de mensajes, no solo podemos lograr un mejor desacoplamiento, sino también utilizar el mecanismo de reinversión de mensajes en caso de falla para aumentar la probabilidad de éxito.

Estado

El modelo de estado significa que en diferentes estados existen diferentes comportamientos de procesamiento.

El flujo de trabajo se introduce en el sistema de transacciones, que define los estados por los que pueden pasar las actividades comerciales y las operaciones que se pueden realizar en cada estado. Por ejemplo, el proceso de cuasi-transacción de garantía ordinaria incluye: nodos de estado como la creación de transacciones de pago externas, devoluciones de llamadas de pago, creación de pedidos logísticos, envío y confirmación de recepción. Cada nodo también define qué operaciones se pueden realizar. Por ejemplo, al crear una transacción de pago externo, se pueden realizar operaciones como verificación de pago, cierre de órdenes y modificación de precios. Sin embargo, operaciones como pago y reembolso no se pueden realizar porque no hay pago. se ha hecho..

Mediador

Cuando es necesario coordinar varias clases, a menudo se introducen intermediarios para la coordinación y reducir los costos de conocimiento de todos.

Durante la ejecución del proceso en el sistema comercial, habrá un gran contexto que coordinará los datos en varios campos. Un escenario típico es que cada nodo de orquestación puede afectar la actualización de datos, que deben almacenarse en algún lugar y luego entregarse al nodo de actualización final. Esta función de transmisión de información suele recaer en el intermediario del contexto. La siguiente es una estructura aproximada de colaboración de actualización en el proceso inverso.

Compuesto

Las combinaciones pueden describir de forma recursiva una jerarquía de objetos a través de patrones heredados y nodos secundarios.

Un mejor ejemplo de pensamiento recursivo es dividir pedidos en el sistema de pedidos, que agrupa continuamente una serie de pedidos. Comprenda de forma lógica, al igual que de forma recursiva para refinar aún más.

único

Singleton significa que en el caso de subprocesos múltiples, es necesario garantizar que el objeto solo se cree una vez como recurso único.

En el sistema de gestión de pedidos, los servicios de llamadas externas se denominan Repo, que sirve como biblioteca de recursos. Para obtener convenientemente estas bibliotecas de recursos, todas se obtienen a través del modo singleton, de modo que algunas clases de herramientas también pueden llamar convenientemente a servicios a través de métodos estáticos sin inyectar beans. Dicho Repo incluye: servicio de pedidos, servicio de evaluación, servicio de íconos, servicio de tiempo de espera, etc.

Intérprete

El intérprete significa que se forma un conjunto de lenguaje para un conjunto de contextos y las tareas correspondientes se pueden completar interpretando el significado de las expresiones.

El modo de intérprete que se ve en las transacciones es principalmente el sistema Newton del sistema Taobao original, una configuración de script dinámica. Esta plataforma de configuración resuelve principalmente algunas reglas dinámicas en el paquete del producto. A través del modo push, la naturaleza dinámica de la interpretación se puede utilizar para reducir algunos costos de implementación.

Apoderado

El propósito de un proxy es empaquetar una clase y realizar un reenvío secundario o algún control sobre las operaciones relacionadas.

En el sistema de gestión de pedidos, para evitar que varios dominios manipulen el contexto, existen ciertas medidas de protección para el contexto. Al ingresar a un nodo de ejecución específico, se realizará la conversión de contexto. Durante el proceso de conversión, el objeto de entidad será proxy envolviendo la interfaz de solo lectura para proporcionar servicios de solo lectura. Sin embargo, no se puede obtener la instancia específica y el conjunto No se puede realizar la modificación.

Resumir

Hay una oración que describe el patrón en "Patrones de arquitectura de aplicaciones empresariales" que está bien escrita:

Cada patrón describe un problema recurrente que nos rodea y el núcleo de la solución a ese problema. De esta manera, podrá utilizar la solución una y otra vez sin duplicar esfuerzos.

Este artículo utiliza algunos principios y patrones de diseño para hablar sobre algunos diseños del sistema comercial que he espiado. Espero poder darle una perspectiva y aprender más sobre el enlace de transacción en mi opinión.

Autor ｜ Tianhe

Haga clic para probar el producto en la nube de forma gratuita ahora y comenzar su viaje práctico en la nube.

Enlace original

Este artículo es contenido original de Alibaba Cloud y no puede reproducirse sin permiso.