Desacoplamiento de Código

English

Podemos recurrir a los siguientes enfoques o estilos arquitectónicos para el diseño y la organización del código en un sistema de software:

Paquete por Capa

Separamos nuestro código fuente en función de lo que hace desde una perspectiva técnica. Se distingue 2 formas:

1. Paquete por Capa (Estricto)	2. Paquete por Capa
Las capas dependen únicamente de la capa inferior adyacente. Las flechas de dependencia siempre apuntan hacia abajo.	Las capas dependen de las políticas de alto nivel. El proyecto utiliza este enfoque en su rama: package_by_layer

La idea central de este enfoque es: "Separar el código desde una perspectiva técnica", y eso es precisamente lo que se visualiza en cada diagrama.

Paquete por Característica

Separamos el código fuente en función de las características relacionadas con el dominio, colocando todo en un solo paquete en lugar de dividirse en múltiples paquetes. Este dominio se refiere al área específica de actividad para la cual se ha diseñado el software, abordando sus problemas y requisitos particulares.

Paquete por Característica
Todas las clases y demás elementos en el paquete realizan funciones relacionadas con el dominio. El proyecto utiliza este enfoque en su rama: package_by_feature

Puertos y Adaptadores

Organizamos el código teniendo en cuenta que el código base solo está compuesto por un interior (dominio) y un exterior (infraestructura).

Puertos y Adaptadores
Este ejemplo puede parecer similar al enfoque de paquete por capa en su segunda forma, pero utiliza los conceptos de puertos y adaptadores de la Arquitectura Hexagonal.

Paquete por Componente

Agrupación de todas las responsabilidades relacionadas con un componente en un único paquete, con una visión centrada en el servicio. La lógica de negocio y el código de persistencia residen en un solo componente general, manteniendo la separación de preocupaciones dentro de este componente y separándolo del código relacionado con la interfaz de usuario.

Paquete por Componente
En este ejemplo, tanto la lógica de negocio como el código de persistencia residen en un solo paquete, con el propósito de ofrecer servicios exclusivamente a través de una abstracción (interfaz). Esta interface se puede llamar componente, pero también considero valido llamarlo servicio, porque eso es justamente lo que ofrece un componente.

El proyecto tiene un intento de este enfoque en su ramas : package_by_component_Main y package_by_component_Secondary

Observación

Aunque la esencia de este enfoque consiste en "Agrupar la lógica de negocio y el código de persistencia en un solo componente", personalmente considero más apropiado decir "Agrupar todas las responsabilidades relacionadas en un solo componente, excluyendo todo lo relacionado con la interfaz de usuario y los mecanismos de entrega". Menciono esto porque podría haber otros conceptos además del código de persistencia que podrían estar contenidos en ese componente de grano grueso.

Encapsulación

La idea general de la encapsulación consiste en ocultar los detalles internos y mostrar solo lo necesario. Para ejemplificar esto justamente todos los diagramas anteriores tienen clases e interfaces que tienen un color gris para indicar que no son visibles para otros paquetes.

Veamos la diferencia entre no aplicar la encapsulación y aplicarla:

Sin Encapsulación	Con Encapsulación
Si todo se marca como público, cualquier enfoque utilizado será inútil y se reduce a un simple mecanismo de organización en lugar de encapsulación.	Aquí hay un adecuado manejo de lo que se muestra y lo que no se muestra, lo que permite una clara delimitación en cada enfoque.

La disciplina no es suficiente

Para hacer cumplir estos enfoques y garantizar que solo ciertas partes del código sean accesibles desde otras partes, necesitamos algo más que disciplina para lograrlo; por ejemplo, especificar que los presentadores no puedan acceder directamente a los repositorios sin antes pasar por los casos de uso. Para lograrlo, contamos con las siguientes opciones:

• Uso de herramientas de análisis estático. (NDepend, Structure101, Checkstyle, JArchitect, y otros).
• Uso del compilador. (Preferible)

Se recomienda siempre confiar en el compilador en la medida de lo posible para cumplir con estos enfoques.

Comparación

Paquete por Capa	Paquete por Característica	Puertos y Adaptadores	Paquete por Componente
✅ Bueno para aplicaciones pequeñas o en fase inicial.	✅ Expone directamente el propósito del dominio	✅ Simplicidad.	✅ Enfoque híbrido de todos los anteriores, minimizando sus defectos.
❌ Difícil de escalar.	✅ Facilidad para localizar el código relacionado con un dominio.	❌ El código de la infraestructura podría eludir el dominio y llamar a otra parte del código de la aplicación.	✅ Cuando necesitas utilizar algún tipo de servicio, solo hay un destino posible.
❌ No revela el objetivo principal del sistema.	❌ Es posible hacer trampas y saltarse niveles.		✅ Facilita la gestión y el mantenimiento del código
❌ Es fácil introducir dependencias no deseadas.