Hace dos años la gente publicó este vídeo y me quedé con la parte de Vertical Slicing por el simple hecho de que Drupal por su propia arquitectura no es posible hacer Arquitectura Exagonal, o lo que sería lo mismo todo estaría en el mismo dominio a menos que se tuviera que programar elementos que si se salieran totalmente de la API habitual de Drupal.

La cuestión es que la arquitectura de Vertical Slicing si que encaja mucho mejor con Drupal. Yo lo que suelo hacer es que cada tipo de nodo es un Slice, luego si algún otro contenido (taxonomías, usuarios, etc....) necesitan mostrar información con su propia URL también pienso en él como un Slice.

Y es aquí donde llego porque estoy montando una página para una taxonomía que en vez de mostrar la información habitual de la taxonomía esta mostrando más información mediante bloques, y al final.

Y es aquí que he tenido la duda de como llamar a los bloques, mi análisis ha sido, para una persona junior un nombre más redundante le va a ayudar a entender el proyecto, para una persona senior tendrá en cuenta el namespace además del nombre del bloque.

Y con esta duda he preguntado a ChatGP/Gemini/Cloude/Deepsheek por curiosidad a ver que me respondían.

La pregunta a todas ellas ha sido la misma:

El proyecto en el que estamos de drupal 10 estamos montando la arquitectura de los módulos custom usando vertical slicing.
Ahora mismo estamos con un módulo que se llama project_term_area_study,
La clase abstracta se llama AreaOfStudyBaseBlock
Uno de los bloques AreaOfStudyDegreeStandardNameListBlock y el otro bloque AreaOfStudyOthersAreaOfStudyBlock
¿Es una nomenclatura correcta?

Y estas han sido las respuestas:

Gemini:

Sí, la nomenclatura que propones es muy buena y sigue las mejores prácticas para una arquitectura de módulos personalizados con "vertical slicing" en Drupal 10.
Analicemos por qué es una nomenclatura correcta y eficaz:

1. Prefijo del Módulo (project_):
   • project_: Es un prefijo claro y consistente para tu organización o proyecto. Esto evita colisiones de nombres con módulos contrib o de terceros, y hace que sea obvio a qué parte de tu codebase pertenece el módulo.
2. Nombre del Módulo (project_term_area_study):
   • term_area_study: Es descriptivo y sigue la lógica de "vertical slicing". Indica que este módulo se enfoca en un concepto o "slice" específico: los términos de taxonomía relacionados con el "área de estudio". Esto es ideal, ya que cada módulo maneja una funcionalidad vertical completa.
3. Clase Abstracta (AreaOfStudyBaseBlock):
   • AreaOfStudy: Coincide directamente con el dominio o "slice" de tu módulo. Es claro que esta clase base está relacionada con la funcionalidad central del módulo.
   • BaseBlock: El sufijo Base es una convención muy común y excelente para clases abstractas que sirven como base para otras clases. Block indica claramente que es una clase base para plugins de bloque.
   • Ubicación: src/Plugin/Block/AreaOfStudyBaseBlock.php (asumiendo que project_term_area_study es el nombre de tu módulo).
4. Bloques Concretos:
   • AreaOfStudyDegreeStandardNameListBlock:
     • AreaOfStudy: Consistente con el dominio del módulo.
     • DegreeStandardNameList: Claramente describe la función específica de este bloque: una lista de nombres de áreas de estudio estándar para grados. Es descriptivo y específico, lo que es clave para el vertical slicing.
     • Block: Identifica que es un plugin de bloque.
   • AreaOfStudyOthersAreaOfStudyBlock:
     • AreaOfStudy: Consistente con el dominio.
     • OthersAreaOfStudy: Describe la función de este bloque, mostrando "otras áreas de estudio". También es específico y claro.
     • Block: Identifica que es un plugin de bloque.
   • Ubicación:
     • src/Plugin/Block/AreaOfStudyDegreeStandardNameListBlock.php
     • src/Plugin/Block/AreaOfStudyOthersAreaOfStudyBlock.php Ventajas de esta nomenclatura en una arquitectura de "Vertical Slicing":
5. Claridad: Cualquiera que vea los nombres de los módulos y las clases puede entender rápidamente su propósito y ámbito.
6. Organización: Facilita la navegación del código. Sabes exactamente dónde buscar la lógica relacionada con un "slice" particular.
7. Modularidad: Refuerza la idea de que cada "slice" es una unidad funcional independiente, lo que facilita el desarrollo, las pruebas y el mantenimiento.
8. Cohesión: Las clases relacionadas con un slice específico están agrupadas, mejorando la cohesión.
9. Bajo Acoplamiento: Promueve el bajo acoplamiento entre los diferentes "slices" o funcionalidades. En resumen, tu nomenclatura es excelente y demuestra una comprensión sólida de las prácticas de desarrollo de Drupal y los principios de diseño de software modernos como el "vertical slicing".

Deepsheek:

Análisis de Nomenclatura en Arquitectura Vertical Slicing para Drupal 10

Tu estructura sigue buenos principios de vertical slicing, pero podemos optimizar la nomenclatura para mayor claridad y consistencia. Aquí tienes mi análisis detallado:

Estructura Actual

project_term_area_study/
  src/
    Plugin/
      Block/
        AreaOfStudyBaseBlock.php (abstracta)
        AreaOfStudyDegreeStandardNameListBlock.php
        AreaOfStudyOthersAreaOfStudyBlock.php

Fortalezas de tu enfoque actual

1. Coherencia con el dominio: Usas "AreaOfStudy" que refleja claramente el bounded context
2. Diferenciación clara: Los nombres distinguen bien los bloques por función
3. Jerarquía visible: La clase base se identifica fácilmente con "BaseBlock" ## Sugerencias de mejora ### 1. Para el módulo: project_term_area_study → Considera:
4. project_area_study (más corto)
5. project_area_study_blocks (si solo contiene bloques) ### 2. Para la clase abstracta: AreaOfStudyBaseBlock está bien, pero alternativas podrían ser:
6. AreaOfStudyBlockBase (más común en Drupal)
7. AbstractAreaOfStudyBlock (más explícito) ### 3. Para los bloques concretos: #### AreaOfStudyDegreeStandardNameListBlock
8. Propuesta: DegreeStandardNameListBlock
9. Razón: El prefijo "AreaOfStudy" es redundante (ya está en el namespace)
10. Alternativa: DegreeStandardListingBlock (más corto) #### AreaOfStudyOthersAreaOfStudyBlock
11. Problema: Redundancia ("AreaOfStudy" aparece dos veces)
12. Propuesta: RelatedAreasOfStudyBlock o OtherAreasBlock
13. Más claro: AreaOfStudyPeerListBlock ## Estructura recomendada

project_area_study/
  src/
    Plugin/
      Block/
        AbstractAreaOfStudyBlock.php
        DegreeStandardListingBlock.php
        RelatedAreasBlock.php

Buenas prácticas observables

1. PascalCase para nombres de clase ✓
2. Sufijo Block para plugins de bloque ✓
3. Agrupación lógica por funcionalidad ✓ ## Consejo adicional sobre vertical slicing Para mantener una arquitectura limpia en vertical slicing:
4. Considera agrupar todos los archivos relacionados (controllers, services, blocks) de cada feature en su propio directorio
5. Ejemplo alternativa:

project/
  area_study/
    blocks/
      AbstractBlock.php
      DegreeListing.php
      RelatedAreas.php
    services/
    controllers/

¿Qué aspecto te gustaría profundizar más? ¿Prefieres mantener la nomenclatura actual o implementar algunos de estos cambios?

Claude:

Analizando la nomenclatura que estás usando para tu módulo de Drupal 10 con vertical slicing, encuentro algunos aspectos que podrían mejorarse:

Análisis de la nomenclatura actual:

Puntos positivos:

• El prefijo project_ mantiene consistencia con tu namespace del proyecto
• term_area_study indica claramente el dominio funcional
• La clase abstracta AreaOfStudyBaseBlock es clara y descriptiva Áreas de mejora:
• Redundancia en nombres de bloques:
  • AreaOfStudyDegreeStandardNameListBlock tiene redundancia con "AreaOfStudy" al inicio
  • AreaOfStudyOthersAreaOfStudyBlock repite "AreaOfStudy" dos veces
• Longitud excesiva:
  • Los nombres son muy largos, lo que puede dificultar el mantenimiento ## Sugerencia de nomenclatura mejorada:

Módulo: project_term_area_study
Clase abstracta: AreaOfStudyBaseBlock ✓ (está bien)
Bloques:
- DegreeStandardNameListBlock
- OtherAreasListBlock

O si prefieres mantener más contexto:

- DegreeNameListBlock  
- RelatedAreasBlock

Justificación:

• Al estar dentro del módulo project_term_area_study, el contexto "AreaOfStudy" ya está implícito
• Los nombres son más concisos pero mantienen claridad semántica
• Siguen las convenciones de naming de Drupal
• Son más fáciles de leer y mantener ¿Te parece mejor esta aproximación o prefieres mantener más contexto explícito en los nombres de las clases?

Chatgpt:

Sí, en líneas generales tu nomenclatura es bastante clara, coherente y alineada con las buenas prácticas de Drupal 10 y la arquitectura vertical slice. Sin embargo, puedo ofrecerte algunas observaciones para hacerla aún más robusta y sostenible:

✅ Cosas que estás haciendo bien

Elemento	Comentario
project_term_area_study	👍 El nombre del módulo es claro, contextualizado y específico.
AreaOfStudyBaseBlock	👍 Nombre adecuado para una clase abstracta base de bloques relacionados.
AreaOfStudyDegreeStandardNameListBlock	👍 Descriptivo y sigue el patrón [Dominio][Propósito][Sufijo].
AreaOfStudyOthersAreaOfStudyBlock	✅ Aunque es largo, también sigue una estructura clara.

---

🧠 Sugerencias opcionales para más claridad o consistencia

1. Evitar repeticiones semánticas innecesarias En AreaOfStudyOthersAreaOfStudyBlock, la repetición de "AreaOfStudy" puede causar ruido.
   • 🔁 Opción alternativa: AreaOfStudyRelatedAreasBlock o OtherAreasOfStudyBlock.
   • Si el contexto ya está claro por el namespace y base class, podrías simplificar sin perder significado.
2. Patrones orientados a propósito o función Si los bloques son listas, menús, selectores o tabs, puede ser útil que el sufijo lo aclare:
   • AreaOfStudyDegreeStandardNameListBlock
     • ✅ está bien.
     • Alternativas (si aplica): AreaOfStudyStandardNamesBlock, StandardNamesListBlock.
3. Consistencia con el namespace del módulo Asegúrate de que el namespace de las clases refleje bien el contexto vertical. Por ejemplo:

```php
namespace Drupal\project_term_area_study\Plugin\Block;

   Y si usas servicios comunes:


    ```php
   namespace Drupal\project_term_area_study\Service;

---

📦 Bonus: carpeta y estructura vertical slice recomendada

project_term_area_study/
├── Plugin/
│   └── Block/
│       ├── AreaOfStudyBaseBlock.php
│       ├── AreaOfStudyDegreeStandardNameListBlock.php
│       └── AreaOfStudyRelatedAreasBlock.php
├── templates/
│   └── block--area-of-study-degree-standard-name-list.html.twig
├── css/ (si aplica)
├── js/  (si aplica)
├── project_term_area_study.module
├── project_term_area_study.services.yml
└── README.md

---

✅ Veredicto final

• Tu estructura es correcta y profesional.
• Solo podrías considerar simplificar algunos nombres para legibilidad si ves que se vuelven redundantes.
• La orientación vertical está clara y bien aplicada al dominio "area of study". Si quieres, puedo ayudarte a revisar o proponer convenciones para otros módulos verticales (project_term_degree_type, etc.) para mantener consistencia global.

Conclusión
Me ha asombrado lo tajante que ha sido Gemini dado que las otras tres han indicado que estaba bien pero se podía mejorar reduciendo la redundancia en los nombres de los bloques y de la clas abstracta.

Por otro lado el contexto del proyecto (que es algo que no he definido en el prompt) también es importante, un equipo que conozca mejor el proyecto, veterano no necesitará nombres tan redundantes mientras que un equipo con menos experiencia en programación, en la arquitectura Vercital Slicing, en el proyecto (al final los nombres de las clases deberían ir determinadas por el negocio y por el Slice.