Modelado e implementación PaaS del sistema de cumplimiento inverso de pedidos | Equipo técnico de JD Cloud

guía

Este artículo se centra en las mejores prácticas técnicas del negocio minorista de comercio electrónico de JD para el cumplimiento inverso de pedidos. La plataforma minorista de reembolso rápido de JD lleva a cabo casi todos los negocios minoristas de interceptación inversa y reembolso de venta anticipada, y ha acumulado una rica experiencia en el diseño de escenarios comerciales y el diseño de la arquitectura en la exploración de tecnología y negocios a largo plazo. Este documento actualiza la arquitectura general del sistema de la solución técnica B-PaaS del grupo y resume un conjunto completo de soluciones que cubren la gestión del proceso de terminación de usuario, la gestión del proceso de cancelación de cancelación, la gestión de información de reembolso inverso del pedido, la configuración del proceso y la visualización del proceso. Después de muchas discusiones y verificaciones, esta solución ha respaldado el crecimiento de múltiples negocios estratégicos del grupo. Después de leer este artículo, los lectores pueden comprender la lógica subyacente del nuevo diseño del sistema de toda la plataforma de respaldo rápido, y también pueden consultar este artículo y combinarlo con escenarios reales para aplicar la solución a la transformación del sistema de deuda heredado, modelado comercial y técnico.

1. Introducción a los antecedentes

Bajo la guía de la estrategia PaaS del grupo, el equipo Lightning Agile a cargo del autor completó la terminación del sistema de retorno rápido y la actualización de la arquitectura B-PaaS de los dos subsistemas en los últimos seis meses.

1. Soporte comercial , comenzando con el proyecto de integración Great Wall del grupo, a través de la actualización y transformación de PaaS, el negocio de reembolso y ajuste de SKU del pedido es compatible con el negocio de reembolso de pedido completo original. Si la actualización de la estructura PaaS no se implementa, el sistema de ajuste y reembolso debe reconstruirse para admitirlo; en el proyecto del centro comercial B, las capacidades de los terminales B y C están integradas, y el equipo del lado de la plataforma del centro de pedidos trabaja en conjunto para reutilizar las capacidades en los nodos del estado original del pedido del terminal C, que integra perfectamente el negocio inverso de la orden de intención del centro comercial B. En el futuro, también se expandirá para respaldar más proyectos estratégicos grupales.

2. Soporte de productos , basado en el negocio complejo del grupo, la plataforma de devolución rápida lleva a cabo casi todos los negocios de interceptación inversa y reembolso de preventa del negocio minorista del grupo. La complejidad del negocio es extremadamente alta, y el producto y la I + D solo se pueden comunicar de manera módulo a persona. Por ejemplo, tome la página de liquidación detallada del negocio como ejemplo. A través de la actualización de la arquitectura PaaS, no solo se ha acumulado el modelado comercial y la visualización de procesos, sino también la construcción de un modelo de dominio y un conjunto de procesos comerciales centrales, y los requisitos de personal para la comunicación del producto se han reducido en un 83 %.

3. Soporte del sistema . En los últimos años, el grupo no solo ha ampliado el negocio de la estación principal, sino que también ha invertido en estrategia y estrategia comercial en el extranjero, y ha construido múltiples sistemas de duplicación de chimeneas. No solo hay muchas capacidades similares en el negocio, sino que también ha aumentado los costos de inversión y mantenimiento de I+D. A través de la actualización de la arquitectura PaaS, el negocio de lotes agrícolas ha sido respaldado por la arquitectura PaaS, y otros negocios también están siendo respaldados por un conjunto de núcleos PaaS y la integración de múltiples subcontratos comerciales verticales. La entrada del personal de mantenimiento se ha reducido a la mitad.

2. Introducción del producto

2.1 ¿Qué es rebobinar?

2.1.1 ¿Qué es el rebobinado rápido a los ojos de los consumidores y usuarios finales C?

Figura 1 Rewind desde la perspectiva de los usuarios finales C

2.1.2 Rebobinar ¿qué hay en otras perspectivas?

C-end: para usuarios C-end, cancelar antes del pago y cancelar después del pago

Comerciantes: para comerciantes POP para ayudar a los usuarios a cancelar en nombre de los usuarios, para comerciantes de tiendas

Operación: Para productos autooperados, cancelar con comercios POP

Atención al cliente: para auditorías financieras anormales y cancelación de quejas de usuarios

Rechazo: Por entregar productos a clientes, no se puede contactar con ellos o el usuario se niega a aceptar

Skynet: interceptación de control de riesgos para usuarios en lista negra, arbitraje o evasión de carga

2.1.3 ¿Qué es rebobinar?

Para resumir en una frase: la plataforma de reembolso rápido está orientada a consumidores, comerciantes, control de riesgos, servicio al cliente y otros roles, proporcionando soluciones de reembolso físico o virtual, y está comprometida con la creación de una plataforma integrada para soluciones de terminación de preventa.

3. Modelado de dominio

3.1 El valor y la necesidad de modelar

Antes de modelar, primero mire la figura a continuación.Esta figura explica principalmente cómo colaboran los expertos del dominio, los gerentes de proyecto, los arquitectos, los equipos de producción e investigación, etc.

Figura 2 El proceso y la necesidad de modelar

De él se pueden extraer palabras clave: dominio del problema, expectativa comercial, diagrama de flujo comercial, análisis de actividad de escenario, límite comercial, límite del producto de la organización del equipo y límite de la arquitectura del sistema de implementación técnica. Resumido en una oración, en un escenario de negocios específico, aclare el dominio del problema en el escenario de negocios, exprese las reglas de negocios a través de elementos y relaciones, y genere la solución al problema actual.

3.2 Preparación del trabajo antes del modelado

3.2.1 Objetivos claros

Desde la perspectiva de los objetivos macro: Enterprise Architecture (Arquitectura empresarial) comenzó en la década de 1960 y se ha estado desarrollando durante casi 60 años. También han nacido muchas arquitecturas y métodos empresariales maduros, como Zachman, TOGAF, DoDAF, etc. Estos marcos de arquitectura empresarial se aplican al diseño de nivel superior de varias empresas y organizaciones. Luego, a través de la planificación y el diseño de la arquitectura empresarial, puede ayudar a la empresa a construir una estrategia digital general, planificar proyectos digitales y ayudarla a lograr los objetivos estratégicos deseados y los resultados comerciales a través de medios digitales, formar la planificación y el diseño digital de alto nivel de la empresa y guiar el proceso de transformación digital de la empresa.

Para construir una arquitectura empresarial moderna, desglosar las islas de datos, eliminar la construcción redundante de chimeneas, utilizar el enfoque PaaS para implementar la arquitectura comercial de gama media y facilitar la transformación digital de las empresas, es necesario clasificar los procesos comerciales de los sistemas comerciales existentes, identificar los puntos de diferenciación, crear un conjunto de intercambio de procesos comerciales centrales y respaldar las capacidades de expansión de múltiples procesos comerciales verticales.

Desde la perspectiva de los microobjetivos: en el proceso de rotación de personal, datos incompletos, pilas de códigos y expansión comercial, el sistema comercial ha profundizado continuamente la dificultad del gobierno de la complejidad del software.Desde la perspectiva de los productos, los antecedentes comerciales están incompletos, las capacidades del producto están incompletas y la I + D no se atreve a modificar la lógica comercial.Con frecuencia, existen problemas como la falta de verificación de los escenarios comerciales en la línea. No solo intensifica el ciclo de entrega de producción e investigación, sino que también disminuye gradualmente en términos de rendimiento de la demanda, dejando solo al equipo de producción e investigación en difícil mantenimiento, lo que restringe el desarrollo de productos y negocios innovadores.

Para mejorar la eficiencia de la entrega de producción e investigación, reducir el ciclo de entrega, aumentar el rendimiento de la demanda y apoyar mejor la innovación de productos y la innovación y el desarrollo empresarial, es necesario optimizar el sistema de productos.

3.2.2 Ver claramente la situación actual

1. Del análisis de los requisitos comerciales: si el lector tiene un equipo de operaciones comerciales fijo, aquí puede basarse en el equipo de operaciones comerciales para analizar, resumir y clasificar los requisitos comerciales, así como las perspectivas futuras. Si no hay un equipo de operaciones comerciales, como el departamento de capacidad básica, a menudo hay muchas partes comerciales que están conectadas y existe un dilema: no hay forma de comunicarse con la empresa, y aquí puede analizar las necesidades comerciales anteriores.

Figura 3 La perspectiva del análisis de requisitos de negocio

2. Análisis desde el espacio del problema: (1) problema comercial: muchas partes comerciales, necesidades comerciales no concentradas; (2) problema del producto: el producto tiene un control débil sobre las necesidades comerciales, los límites del producto son borrosos, la industria carece de soluciones maduras y la cognición de la producción y la investigación no está unificada; (3) problema del sistema: el modelo comercial es caótico, hay muchas dependencias aguas arriba y aguas abajo, y el proceso comercial es complicado y difícil de explicar con claridad.

Figura 4 Perspectivas del análisis del espacio del problema

3.2.3 Encontrar una solución

Como se puede ver de lo anterior, todos los problemas antes mencionados no se pueden evitar aunque solo sea desde el modelado de negocios, y la relación entre negocio-organización-tecnología-operación es interdependiente. Luego, debe resolverse desde dos aspectos: uno es el proceso del mecanismo organizativo, que se puede resumir como requisitos y gestión de productos, el otro es el gobierno de la complejidad del negocio del sistema, que se puede resumir como gestión del sistema.

1. Gestión de requisitos y productos

A partir del punto de dolor, analice el proceso de demanda de entrega de producción e investigación, resuma la solución e implemente la implementación estandarizada y racional de la herramienta para garantizar la demanda.

Figura 5 Gestión de requisitos y productos

2. Administración del sistema

Lo anterior ha estandarizado la gestión de la demanda y los problemas del producto, entonces, ¿cómo lidiar con los problemas y puntos débiles a nivel del sistema? Aquí viene el problema que el modelado puede resolver, y solo se enfoca en cómo hacer que el sistema soporte mejor el negocio a nivel de sistema.

3.3 Desafíos de modelado

Desafíos del sistema: el sistema es lo suficientemente complejo, con casi 6 años de aplicaciones antiguas acumuladas en código, el área más afectada por las necesidades estratégicas del grupo. Desafíos organizativos: formación de nuevos equipos, nuevo equipo de producción e investigación, datos antiguos e incompletos. La comunicación industria-industria-investigación sin lluvia de ideas requiere la entrega diaria de requisitos. La expresión de 9 palabras es centrarse en puntos clave, hacer avances y expandirse de manera integral.

Figura 6 Desafíos en el modelado

3.4 Cómo modelar

Guiado por el pensamiento de la arquitectura empresarial moderna, cree un metamodelo de arquitectura empresarial, integre el negocio, las operaciones, la organización y la tecnología, e implemente la arquitectura empresarial mediante el modelado de procesos, el modelado de dominios, el modelado de identidad empresarial y el modelado de capacidades.

Figura 7 Proceso de modelado

3.4.1 Modelado de procesos

Comience con las reglas de operación comercial, ordene el proceso y separe la lógica comercial de la lógica del dominio. La siguiente figura es un ejemplo, desde el usuario que cancela el pedido hasta el reembolso final.

Figura 8 Modelado de procesos

Al ordenar las reglas operativas, en realidad es el primer paso para restaurar el proceso comercial, pero ¿cómo dibujar el límite comercial en este momento? El aislamiento se puede realizar a través de contratos de interfaz. Mirando la figura a continuación, es mucho más clara, y la lógica comercial y la lógica de dominio también están separadas.

Figura 9 Límites comerciales claros a través de contratos de interfaz

A partir del proceso anterior, en realidad podemos encontrar que hay aplicaciones basadas en pedidos, comerciantes/almacenamiento basados ​​en pedidos de producción, entrega basada en guías de embarque, servicio al cliente para pedidos de auditoría y reembolsos de facturas. Por lo tanto, este modelo se puede simplificar. Este modelo solo se divide en 4 módulos lógicos, que son la solicitud de rescisión del contrato, la intercepción de la rescisión del contrato (revisión del comerciante/intercepción del almacenamiento/intercepción de la entrega), la revisión de la rescisión del contrato (revisión del servicio al cliente/revisión financiera) y el efecto de rescisión del contrato (reembolso financiero). Este modelo es abstracto y relativamente simple.

Figura 10 Modelo simplificado

3.4.2 Modelado de dominio

Construya un modelo de dominio único descontracturado para describir los "huevos" que se ven comúnmente. En primer lugar, el dominio comercial se divide en 5 dominios, excepto el formulario de rescisión del contrato, que son los cuatro subdominios principales en el modelado de procesos anterior, el dominio de la aplicación, el dominio de la rescisión del contrato, el dominio de revisión y el dominio de validación. Los objetos de dominio se dividen en formulario de solicitud de rescisión de contrato, formulario de intercepción de rescisión de contrato, formulario de revisión de rescisión de contrato y formulario efectivo de rescisión de contrato.

Figura 11 Construcción del "huevo" del modelo de dominio único

A continuación, unifique el lenguaje comercial, analice las actividades de eventos del dominio y desmonte los servicios del dominio (el contenido de la información enfatizado aquí es ligeramente diferente de los servicios del dominio DDD, y se pone más énfasis en el microcosmos, como la latitud de la interfaz RPC).

Figura 12 Tabla de idioma común

A continuación, analice los eventos y actividades del dominio y desmantele los servicios del dominio, deposite los servicios del dominio, las capacidades del dominio y las diferencias entre los diferentes negocios verticales para extraer puntos de extensión.

Figura 13 Análisis de actividad de eventos de dominio

Figura 14 Desmantelamiento de servicios de dominio

El diseño del proceso empresarial basado en la excelente gestión del ciclo de vida de nginx y asp.net también es similar al método anterior.

Figura 15 Diseño de procesos de negocio

3.4.3 Identidad comercial y modelado de datos

La identidad comercial es la identificación única para diferentes partes comerciales, que distingue cada sistema comercial, la identidad comercial se divide en identidad comercial vertical e identidad comercial horizontal. Desde la perspectiva de los objetivos comerciales: use identidades comerciales para aislar la lógica comercial de las necesidades de las diferentes partes comerciales, y la plataforma intermedia usa las identidades comerciales como la línea principal para potenciar varios escenarios personalizados para diferentes partes comerciales. Desde la perspectiva de los objetivos técnicos: la base central para posicionar los puntos de extensión durante el tiempo de ejecución del sistema y la realización de cada punto de extensión está directamente vinculada a la identidad comercial.

**Aclare la definición de identidad comercial vertical: **La capacidad de proporcionar bienes o servicios de manera independiente y llevar a cabo actividades comerciales de manera independiente sin depender de otras líneas comerciales se denomina negocio vertical.

**Definición clara de negocio horizontal:** No puede proporcionar bienes o servicios de forma independiente, debe depender de bienes o servicios incluidos en otros negocios y debe combinarse con otras reglas comerciales para completar actividades comerciales completas. Como seckill, lucha para comprar, etc. El negocio horizontal es la forma de expresar estructuralmente los activos comerciales acumulados en China y Taiwán en el futuro.

**Definición clara de escenario:** El escenario es una identificación de aislamiento de lógica empresarial más detallada bajo la identidad empresarial vertical. Cuando hay pocas diferencias de lógica empresarial (a nivel técnico, es decir, la cantidad de puntos de extensión con diferentes implementaciones es pequeña), los escenarios se pueden usar para el aislamiento lógico. Su uso es más ligero que el negocio vertical.

Las reglas comerciales entre negocios verticales y negocios horizontales se pueden superponer. Cuando se producen conflictos de reglas comerciales, se debe juzgar la prioridad comercial. Sin embargo, las reglas comerciales entre múltiples negocios verticales no se pueden superponer. Una regla de negocio completa se compone de una regla de negocio vertical + N reglas de negocio horizontales.

Figura 16 Negocio vertical y negocio horizontal

Una vez que se define la identidad comercial, se lleva a cabo el mapeo del modelo de datos. Por ejemplo, se utilizan 7 identidades comerciales nuevas e identidades comerciales autooperadas para el modelado de datos, que se definen por vertical, horizontal y central.

Figura 17 Mapeo del modelo de datos

3.5 Validación del modelo

Después del modelado, muchos usuarios están más angustiados si el modelo coincide con el negocio. En otras palabras, si el modelo restaura el escenario de actividad comercial real 1:1, entonces la verificación o deducción del modelo es en realidad el núcleo de la construcción del modelo.

Coincidentemente, en el rebobinado rápido, debido a que el autor desempeña múltiples roles, líder de equipo, arquitecto, y también debe realizar la evaluación de las necesidades de I+D de primera línea, por lo que resumió un conjunto de arquitectura modelo basada en mensaje mensaje, que restaura la escena empresarial real y guía la implementación de I+D.

Figura 18 Validación del modelo

4. Implementación de B-PaaS

4.1 Guía de arquitectura de ingeniería B-PaaS

Actualice la arquitectura del sistema en función de la arquitectura de ingeniería de PaaS:

Figura 19 Actualización y transformación de la arquitectura del sistema

Por ejemplo, la estructura del proyecto de aterrizaje es la siguiente:

Figura 20 Estructura del proyecto de aterrizaje

4.2 Implementación de PaaS en casos de demanda real

4.2.1 Análisis de procesos comerciales

A través del análisis de procesos basado en los documentos de integración del negocio B mall y el negocio C mall, el diagrama de análisis es el siguiente, identificando el dominio comercial, el proceso general y el diseño de puntos variables, para ayudar en la construcción de la separación lógica comercial de los puntos central y de extensión.

Figura 21 Diagrama de análisis de procesos de negocio

4.2.2 Análisis de las actividades del dominio empresarial

Desmonte los eventos del dominio, identifique los objetos del dominio y los subdominios comerciales correspondientes, y ayude a I+D a separar la lógica empresarial y la lógica del dominio.

Figura 22 Diagrama de análisis de las actividades del dominio empresarial

Desarrollo impulsado por mensajes basado en dominio, implementación de mapeo de código de estructura de proyecto y orquestación de procesos a través del dominio principal.

Figura 23 Asignación de mensajes y dominios

4.2.3 Identificación comercial

A través del mapeo de la identidad comercial registrada por el Pabellón Cangjing, se encuentran los elementos de análisis de identidad comercial del sistema local correspondientes para identificar la identificación comercial.

Figura 24 Mapeo de identidad comercial

Figura 25 Identificar identificación comercial

5. Visualización de la capacidad

En el apartado anterior se realizó la implementación de la ingeniería B-PaaS y finalmente se visualizó y reportó la habilidad con la ayuda del Pabellón de las Escrituras Tibetanas, se reportó el proyecto del autor a través de anotaciones.

Figura 26 Informes visuales de capacidades

Figura 27 Configuración de informes y capacidad de informe de comentarios

6. Resumen

A través de los 6 módulos anteriores de antecedentes, producto, modelado, ingeniería, visualización e implementación de demanda real de proyectos B-PaaS, este artículo generalmente presenta por qué la plataforma de rebobinado debe someterse a una transformación de ingeniería PaaS y cómo implementar la actualización de la arquitectura. Se espera que a través de este artículo, los lectores puedan comprender mejor el sistema de cumplimiento inverso de pedidos. Al mismo tiempo, se espera que cuando los lectores se enfrenten solos a sistemas heredados complejos, puedan aprender de las ideas de actualización de arquitectura de este artículo para resolver la complejidad del sistema y del negocio, de modo que el sistema pueda respaldar el desarrollo comercial de manera más eficiente. Además, los lectores también pueden dejar un mensaje para discutir e intercambiar, si se han encontrado con un sistema de deuda heredado complejo y cómo resolverlo.

Autor: JD Retail Liu Xiaocheng

Fuente: Comunidad de desarrolladores de JD Cloud

RustDesk 1.2: Usando Flutter para reescribir la versión de escritorio, apoyando a Wayland acusado de deepin V23 adaptándose con éxito a los lenguajes de programación WSL 8 con la mayor demanda en 2023: PHP es fuerte, la demanda de C/C++ se ralentiza ¿ React está experimentando el momento de Angular.js? El proyecto CentOS afirma estar "abierto a todos" Se lanzan oficialmente MySQL 8.1 y MySQL 8.0.34 Se lanza la versión estable de Rust 1.71.0
{{o.nombre}}
{{m.nombre}}

Supongo que te gusta

Origin my.oschina.net/u/4090830/blog/10089595
Recomendado
Clasificación