Présentation technique des applications

Backend

Structure et nommage des fichiers

├── config
│   └── FooConfig.kt
├── domain
│   ├── entities
│   │   └── foo
│   │       └── Foo.kt
│   ├── exceptions
│   │       └── FooException.kt
│   ├── filters
│   │       └── FooFilter.kt
│   ├── mappers
│   │       └── FooMapper.kt
│   ├── repositories
│   │   └── (I)FooRepository
│   ├── Utils.kt
│   └── use_cases
│       └── foo
│           ├── dtos
│           │   └── FooDTO.kt
│           └── CreateOrUpdateFoo.kt
├── infrastructure
│   ├── api
│   │   ├── adapters
│   │   │   ├── bff
│   │   │   │   ├── inputs
│   │   │   │   │   └── foo
│   │   │   │   │       └── CreateOrUpdateFooDataInput.kt
│   │   │   │   └── outputs
│   │   │   │       └── foo
│   │   │   │           └── FooDataOutput.kt
│   │   │   └── publicapi
│   │   └── endpoints
│   │       ├── bff
│   │       │   ├── FooController,kt
│   │       │   └── BarControllerV[0-9].kt
│   │       └── publicapi
│   │           ├── FooController.kt
│   │           └── BarControllerV[0-9].kt
│   ├── database
│   │   ├── models
│   │   │   └── FooModel.kt
│   │   └── repositories
│   │       ├── interfaces
│   │       │       └── (I)DBFooRepository.kt
│   │       └── JpaFooRepository.kt
│   ├── monitorenv/monitorfish/rapportnav
│   └── Utils.kt
└── utils
    └── GlobalFooer.kt

Générateur d'arbre utilisé : https://www.text-tree-generator.com.

Questions

• Mélange de différents types de nommage : parfois suffixes, parfois prefixes.
• Confusion dans le nommage des repository domain et des repository infrastructure, même chose pour les interfaces. Les repository domain définissent les repository infrastructure et les infrastructure/repositories/interfaces représentent les query DB.
• Versioning via de sous-dossier, des suffixes, des sur-dossiers, ou internes en suffixant les noms des méthodes ?
• Acronymes all cap ou camel-cased ?
• Remise en question des dossiers inputs/ et outputs/ dans le dossier adapters => pourquoi pas directement dans adapters ?
• Suffixe des entités ?
• Utils / structure : par sous-dossier relatif, globaux ou les deux selon qu'ils soient globaux ou dédiés ?
• Utils / fonctions : rassemblés sous la même classe en plusieurs méthodes ou séparés en un fichier par fonction ?

Suggestions

• Nommage :
  • On suffixe tous les fichiers par leur rôle à l'exception des :
    • entities
    • use cases
    • utils
  • Singulier à l'exception des dossiers structurels (entities/, utils/, etc) et des fichiers dédiés à des collections (GetFoos). On avait déjà décidé de ça normalement.
• Confusion repo/interface, proposition de structure/nommage :

  /domain
    /repositories
       /FooRepository.kt
  /infrastructure
    /queries
      /FooQueryRepository.kt
    /repositories
      /JpaFooRepository.kt

• Config : Tout dans un config/ au même niveau que domain/ et infrastructure/.
• Versionning : en suffixant les méthodes des classes (getAllV1(), executeV1()) pour :
  • éviter de complexifier encore un peu plus la structure des dossiers ;
  • éviter d'avoir à faire le choix de "quand un sur-dossier, quand un sous-dossier ?" ;
  • pour simplifier le codage en évitant d'avoir à ouvrir plusieurs fichiers similaires (v1/foo/FooController, v2/foo/MyController).
• Acronymes all cap ou camel-cased : Camel-cased car je trouve ça plus lisible mais c'est peut-être une affaire de goût. => Quoique soit le choix, je suggère qu'on fasse le même choix pour le Frontend.
• Adapters : Supprimer les dossiers intermédiaires inputs/ et outputs/ car les suffixes et les sur-dossiers métiers qui les rassemblent me paraissent assez clairs pour en différencier l'usage.
• Suffixe des entités : Pas de suffixe.
• Utils / structure : Comme dans le Frontend, au niveau qui correspond à leur utilisation.
• Utils / fonctions : Comme dans le Frontend, en plusieurs fichiers pour les utils globaux, un seul fichier avec plusieurs méthodes lorsqu'ils sont localisés (pour éviter d'ajouter des sous-dossiers supplémentaires ?).