Présentation technique des applications

Backend

Structure et nommage des fichiers

/
├── config
├── domain
│   ├── entities
│   │   └── foo
│   │       └── Foo.kt
│   ├── exceptions
│   │       └── FooException.kt
│   ├── filters
│   │       └── FooFilter.kt
│   ├── mappers
│   ├── repositories
│   │   └── (I)FooRepository
│   └── 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

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 sont en réalité des interfaces pour les repository infrastructure et les infrastructure/repositories/interfaces sont en réalité 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 tout par son 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.
• 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.
• 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 ?).