Ya es un hábito para los desarrolladores dividir el sistema JavaWeb en Controlador / Servicio / Dao y otros niveles. Bajo la guía de esta idea en capas, la estructura del paquete en el sistema generalmente es así:
Por supuesto, a veces beans y dao se denominarán model, pojo o mapper, aunque los nombres son diferentes, pero el significado es similar. Si la estratificación está bien, puede haber negocios, jms o paquetes de tareas.
En este tipo de estructura de paquetes, el código de una determinada función (como la función de administración de usuarios) se divide en tres capas: Controlador, Servicio y Dao, y se coloca en sus respectivos paquetes, lo que está en línea con la idea habitual de capas. Y se ve simple y claro. No es de extrañar que esta estructura pueda ser popular en el sur y el norte, y durará para siempre.
Sin embargo, a medida que el sistema se hace cada vez más grande y el negocio se vuelve más complicado, tengo nuevas ideas sobre cómo configurar la estructura del paquete en el sistema y cómo organizar el código.
La idea es simple: al dividir la estructura del paquete dentro del sistema, primero divida el negocio en capas.
Como comparación, el método original se dividió en capas y luego en negocios. Similar a esto:
La imagen de arriba es la estructura del paquete de uno de nuestros sistemas (com.company.system está oculto). Esta imagen muestra claramente cómo la estructura del paquete tradicional "primero se divide en capas, luego divide el negocio". Primero clasifica las clases en paquetes de controlador o servicio (por supuesto, dao, bean, etc.) según el nivel del código; luego, dentro del paquete como controller / service / dao / bean, luego según la función comercial a la que pertenece la clase Se asignan a diferentes paquetes.
De hecho, este sistema es más "delicado". La mayoría de los sistemas pueden simplemente juntar las clases en el mismo nivel después de dividir la estructura del paquete de acuerdo con la jerarquía a la que pertenecen, y ya no dividirlas por negocios.
La estructura del paquete de "dividir en capas primero, luego dividir en negocios" debería ser familiar para nosotros. Entonces, ¿cómo se ve la estructura del paquete de "dividir el negocio primero, luego dividir en capas"? Aún utilizando el sistema anterior como ejemplo, y dividiendo la estructura del paquete de una manera nueva, debería verse así:
En otras palabras, cada clase se colocará primero en diferentes paquetes (como autenticación, usuario, etc.) de acuerdo con la función comercial a la que pertenece, y luego se dividirá en controlador / servicio / dao u otros paquetes de acuerdo con el nivel al que pertenece. Si usa una imagen para explicar la base para dividir las dos estructuras de paquetes, probablemente sea así:
Independientemente del nivel de prioridad o del negocio prioritario, la atención se centra en cómo dividir y gestionar la complejidad. Ambos métodos tienen sus propios méritos, y nadie es mejor que nadie. Por lo tanto, no hablaré sobre lo que está mal en "dividir el negocio primero, luego dividir el negocio", solo hablar de por qué me gusta "dividir el negocio primero, luego dividir el negocio".
En ese momento estábamos refactorizando un módulo. Este es un módulo de cálculo. Es muy importante y se llama con mucha frecuencia. Los resultados del cálculo antes y después de la reconstrucción deben ser exactamente los mismos; al mismo tiempo, es muy complicado. Incluso después de pruebas exhaustivas, no nos atrevemos a garantizar la función correcta. Por lo tanto, publicamos un registro muy detallado en el nuevo código para garantizar que cualquier llamada pueda rastrear cada variable en cada paso.
Obviamente, esta estrategia conducirá a un aumento en el volumen de registros en línea. Después de conectarse, el registro de este módulo alcanzó 15G / día. Tres días después, recibimos la alarma de que "el espacio libre en disco es inferior al 10%". Por supuesto, gracias a un registro tan detallado, solucionamos tres problemas funcionales el primer día después de estar en línea; al tercer día, analizamos y encontramos un cuello de botella en el rendimiento (optimizamos el promedio de 250ms + llamadas a 35ms Izquierda y derecha). Después de completar estas soluciones de problemas y optimizaciones de rendimiento, observamos otro día para asegurarnos de que la refactorización alcanzara su objetivo.
Finalmente, en el quinto día, cambiamos dos líneas de configuración en log4j2.xml para reducir el volumen de registro a menos de 1G / día. Estas dos líneas de configuración son así:
<!-- 原先下面这行配置的level为INFO -->
<Logger name="com.company.system.calculate" level="WARN" />
<!-- 原先没有下面这行配置 -->
<Logger name="com.company.system.calculate.web" level="INFO" />Creo que todos pueden entender el papel de estas dos líneas de configuración de un vistazo. La razón por la cual podemos usar una configuración de dos líneas tan simple para reducir tanto volumen de registro, la primera razón es que nuestra estructura de paquete se "divide primero en negocios, luego se divide en capas". Este es el primer beneficio que obtengo al usar esta estructura de paquete.
Por supuesto, este beneficio no es convincente: ajustar el resultado del registro no es un punto de dolor. Sin embargo, a medida que reestructuramos aún más el sistema, "dividir el negocio primero y luego dividir las capas" mostró otra ventaja.
Como se mencionó anteriormente, este módulo de cálculo es importante, complejo y estresante. Luego decidimos dividir este módulo en un servicio independiente. Después de la primera refactorización, ya tenemos un conjunto de códigos con buena función, rendimiento y estructura. Entonces, durante la segunda refactorización, no planeamos escribir otro conjunto de código, sino que solo planeamos copiarlo.
Esta copia es extremadamente simple y fluida, porque el código central de este módulo está en el mismo paquete. Después de mover este paquete, solo queda una pequeña cantidad de código común y configuración. Por lo tanto, completamos la reconstrucción del segundo sistema con mucha facilidad.
Este es el segundo beneficio que aporta la estructura del paquete de "dividir el negocio primero, luego dividir las capas". Este beneficio no parece ser convincente: no todos los módulos y códigos siempre deben estar preparados para dividirse en servicios independientes.
Pero todavía prefiero la estructura del paquete de "dividir el negocio primero, luego dividir las capas". Implica una estructura de sistema e ideas de diseño que están más inclinadas a los productos, más a la abstracción empresarial, más a la modularización y el servicio. Aunque este argumento todavía no es convincente.
Por lo tanto, no hay distinción en cuanto a si hay una "primera división de negocios, luego una jerarquía" o "una primera división de jerarquía, luego una división de negocios". Es solo que cada elección y cada decisión que tomamos en el diseño y desarrollo del sistema debe ser el resultado del pensamiento, la comparación y las compensaciones, no solo lo mismo.
