Recientemente, tomé la iniciativa en resolver la racionalidad de la arquitectura del sistema del departamento. Antes de comenzar a trabajar, lo primero que pensé fue en cómo definir la racionalidad de la arquitectura.
Desde la perspectiva de la investigación y el desarrollo, si el contexto del sistema es claro, el diseño de la arquitectura de la aplicación es simple y la división de la aplicación es razonable, debería denominarse arquitectura razonable.
Con base en la definición anterior, la evaluación se puede clasificar a partir de los tres aspectos siguientes:
1. El contexto del sistema es claro: conozca claramente la relación de la llamada con el sistema circundante y el mecanismo de sincronización de datos;
2. El diseño de la arquitectura de la aplicación es simple: la arquitectura tiene capas razonables, el posicionamiento de la función es claro y no habrá cosas fuera de los límites funcionales;
3. División razonable de aplicaciones: la granularidad de las aplicaciones en el sistema está dentro de un rango razonable y el enlace de llamada entre aplicaciones no debe ser demasiado largo.
El contexto del sistema es claro.
El término diagrama de contexto del sistema se tomó prestado por primera vez del modelo C4 de Simon Brown, que "expresa de manera abstracta el significado de la arquitectura redefiniendo cuadros y líneas discontinuas en diferentes niveles de abstracción".
El modelo C4 divide el sistema en cuatro capas y cada capa representa una arquitectura de vista diferente con diferentes preocupaciones. La primera capa, el contexto del sistema, es la abstracción de alto nivel del sistema.
La siguiente figura muestra la interacción entre diferentes sistemas en el proceso de navegación de cuentas bancarias personales. Si consideramos el sistema de banca por Internet como nuestro sistema objetivo, entonces el sistema de correo electrónico y el sistema bancario MarinFrame son los sistemas que lo acompañan, que también pueden denominarse sistemas externos, que proporcionan valor del sistema al sistema de banca por Internet, que están fuera del sistema y son negros. cajas.
El contexto del sistema define la relación entre el sistema objetivo y el sistema externo y, junto con el sistema externo, proporciona valor al usuario objetivo. Al dibujar el contexto del sistema, debe prestar atención a la dirección de las dependencias entre el sistema de destino y los sistemas externos. La dependencia hacia el norte significa que el sistema externo llama al servicio del sistema objetivo y es necesario considerar qué tipo de contrato de servicio define el sistema objetivo; la dependencia hacia el sur significa que el sistema objetivo llama al servicio del sistema externo y es necesario para comprender la interfaz, el método de llamada y la comunicación del sistema externo Mecanismos, e incluso qué debe hacer el sistema de destino cuando el sistema externo falla.
Además de referirse al método de dibujo anterior, también se puede representar mediante un diagrama de secuencia comercial. Nació del diagrama de secuencia de UML. Los diagramas de secuencia pueden comenzar con los roles de la izquierda, mostrando el orden en que se pasan los mensajes. Esto implica este tipo de fuerza impulsora: partimos de los objetos participantes de la izquierda, buscamos los pasos de ejecución para cooperar con ellos y luego deducimos todo el proceso de colaboración completo capa por capa.
El diagrama de secuencia empresarial representa la abstracción del sistema a nivel empresarial, la relación de colaboración entre el sistema objetivo y el sistema externo, y el sistema participante es un todo completo, por lo que no necesita ni debe participar en los detalles del sistema interno. La implementación del sistema y la dirección del mensaje son más importantes, muchos representan la responsabilidad del sistema. El diagrama de secuencia empresarial se ve así:
Diseño de arquitectura de aplicaciones simple
La aplicación en sí tiene una arquitectura en capas. Martin Fowler propuso en "Patrones de arquitectura de aplicaciones empresariales" que una capa de sistema razonable debería incluir la capa de presentación, la capa lógica de dominio y la capa de fuente de datos. La capa de presentación proporciona principalmente servicios y maneja las solicitudes de los usuarios. La capa de dominio es la lógica de procesamiento y es el núcleo del sistema. La capa de origen de datos se comunica con la capa de datos, el sistema de mensajes y otros paquetes de software.
El desarrollo posterior del diseño de la arquitectura basada en dominios evolucionó a cuatro capas, agregando la capa de aplicación debajo de la capa de presentación y cambiando la capa de fuente de datos a la capa de infraestructura, rompiendo las limitaciones del sistema de administración de bases de datos.
Según las capas del sistema anteriores, ya sea que adopte una arquitectura de tres niveles o una arquitectura de cuatro niveles, la aplicación representa el límite funcional y proporciona esas capacidades centrales, lo que se puede hacer y lo que no se puede hacer.
Una buena experiencia práctica es consultar la metodología del dominio empresarial del diseño impulsado por dominio, clasificar los dominios de primer, segundo y tercer nivel del sistema, no exceder los cuatro niveles como máximo y definir los dominios en todos los niveles. . Una buena definición de dominio representa los límites de las capacidades del sistema, lo que le permite comprender lo que se puede y lo que no se puede hacer.
Con base en la definición y los límites de capacidad del dominio comercial del sistema ordenados anteriormente, generalmente clasificamos dos tipos de sistemas. El primer tipo es un sistema existente con iteraciones relativamente frecuentes de requisitos. La clave para este tipo de sistema es clasificar ¿Cuáles son las capacidades principales, si están dentro de la definición de dominio del sistema anterior, si otros sistemas tienen capacidades similares y, de ser así, deben considerar la posibilidad de fusionarse? Además, también es necesario considerar la apertura y documentación de las capacidades centrales, al menos informar al departamento y tener un lugar para verificar, para evitar la creación repetida de la rueda del sistema.
El segundo tipo de sistema encontrado es un sistema de stock y no hay iteración de demanda, y básicamente no hay volumen de llamadas en el negocio. Este tipo de sistema necesita comunicarse con la empresa si existe un plan fuera de línea, si existe un sistema similar que pueda reemplazarse y proporcionar referencia técnica para la toma de decisiones comerciales.
División de aplicaciones razonable
En el desarrollo de requisitos, la realización de un proyecto o requisito puede requerir la colaboración de múltiples sistemas de destino, lo que implica la granularidad de la división del sistema de destino. No existe un estándar uniforme para la granularidad de la división de un sistema en aplicaciones, pero debe estar dentro de un rango relativamente razonable. Los factores que se pueden considerar incluyen la planificación comercial, la magnitud de las llamadas al sistema, el diseño de arquitectura basado en la planificación comercial, el número de personas en el departamento y la división del trabajo. Demasiado o muy poco es malo.
Si un nuevo negocio no ve un desarrollo importante en el corto plazo, se puede dividir de manera general al planificar inicialmente la solicitud. El número promedio de personas en el departamento no debe exceder de 2 a 3 solicitudes. Si hay más aplicaciones, inevitablemente llegará un momento en el que se cumplan los costos de cambio entre diferentes sistemas. Si el negocio de seguimiento se desarrolla y el número de personas en el departamento aumenta, debido a que la división del trabajo es más fina, se puede considerar una división más detallada. La división del sistema inevitablemente traerá otro problema: cómo coordinar entre sistemas. y cómo vincular la duración de las llamadas al sistema.
Según el concepto de capas de sistemas mencionado anteriormente, los sistemas del departamento se pueden dividir en dos tipos, un tipo es la puerta de enlace comercial y el otro es la capacidad comercial general. La puerta de enlace empresarial está orientada al usuario y se utiliza para coordinar las actividades de la aplicación. No contiene lógica empresarial ni retiene el estado de los objetos comerciales. Es equivalente a una capa de aplicación de diseño impulsada por dominio + capa de presentación. Algunas personas lo llaman SOA empresarial. o capa BFF.
La capacidad comercial general es equivalente a la capa lógica de dominio + capa de infraestructura. Como núcleo del software, retiene el estado del objeto comercial y la persistencia del objeto comercial se confía a la capa de infraestructura. La capa de infraestructura sirve como la capa de soporte para que otras capas se den cuenta Para comunicarse con otros sistemas, se da cuenta de la persistencia de los objetos comerciales.
En los dos tipos de sistemas anteriores, la puerta de enlace de servicio depende de la capa de capacidad de servicio general, la puerta de enlace de servicio depende de la dirección norte y la capa de capacidad de servicio general depende de la dirección sur. No se recomienda que la longitud del enlace no exceda 2 en una implementación funcional. Al mismo tiempo, también debemos prestar atención a la interdependencia entre sistemas y prestar atención a este punto, que es un punto de riesgo para la estabilidad del sistema.
Cuantificación de Costos:
Con base en el análisis de los tres aspectos anteriores, los entregables se clasificaron: 1. La dependencia del contexto del sistema, 2. La definición del dominio empresarial y el mapa de planificación de capacidad del sistema. 3. La longitud del enlace de llamada de la aplicación y las dependencias mutuas; 4. La evaluación de la racionalidad de la granularidad dividida de la aplicación; 5. La hundimiento o fusión de capacidades en el sistema; 6. Una lista de sistemas con menos volumen de negocios.
Entre ellos, 1-4 puede considerarse como la guía de acción o principio del sistema, y 5-6 es el siguiente paso de acción. Más simplemente, es el apagado y reinicio del sistema que hacemos a menudo. Cuando el sistema del departamento comercial se cierra y se transfiere, también es necesario considerar la cuestión del costo y hacer un buen trabajo al cuantificar el costo.
En primer lugar, es necesario evaluar el costo de apagar y cambiar, y en segundo lugar, evaluar el costo del mantenimiento diario del sistema durante 1 a 3 años, incluido el costo de la mano de obra y los recursos mecánicos. Se resta el valor acumulado del primero y del segundo, si es mayor que cero se recomienda no mover el sistema por el momento, si es menor que cero se puede considerar el plan de apagado y volcado.
Lo anterior son mis pensamientos sobre la racionalidad de la arquitectura del sistema desde la perspectiva de I + D.
Si la racionalidad de la arquitectura se evalúa desde una perspectiva empresarial, puede convertirse en los tres aspectos siguientes: primero, puede resolver las necesidades y problemas empresariales actuales. 2. Cumplir de manera eficiente los requisitos comerciales: puede resolver todos los problemas comerciales actuales de una manera elegante y reutilizable. 3. Diseño con visión de futuro: puede satisfacer al negocio de la segunda forma durante un período de tiempo en el futuro, de modo que no provocará cambios trascendentales en la estructura cada vez que el negocio evolucione.
Diferentes perspectivas significan necesariamente que cada uno tiene puntos de vista diferentes sobre la misma cosa.
Se lanzó Redis 7.2.0, la versión de mayor alcance, los programadores chinos se negaron a escribir programas de juegos de azar, se extrajeron 14 dientes y el 88% de todo el cuerpo resultó dañado. Se lanzó Flutter 3.13. System Initiative anunció que todo su software Sea de código abierto. Apareció la primera aplicación independiente a gran escala, Grace cambió su nombre a "Doubao". Spring 6.1 es compatible con subprocesos virtuales y JDK 21. Tableta Linux StarLite 5: Ubuntu predeterminado, Chrome 116 de 12,5 pulgadas lanzado oficialmente . Red Hat redistribuyó el escritorio. Desarrollo de Linux, el desarrollador principal fue transferido Kubernetes 1.28 lanzado oficialmenteAutor: Jingdong Retail Gao Tianlin
Fuente: Reimpreso por JD Cloud Development Community, indique la fuente