Présentation technique des applications

Backend

Structure et nommage des fichiers

├── domain
│   ├── config
│   │   └── FooConfig.kt
│   ├── entities
│   │   └── foo
│   │       └── Foo(Entity).kt
│   ├── exceptions
│   │       └── FooException.kt
│   ├── filters
│   │       └── FooFilter.kt
│   ├── mappers
│   │       └── FooMapper.kt
│   ├── 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
│   ├── config
│   │   └── FooConfig.kt
│   ├── database
│   │   ├── models
│   │   │   └── FooModel.kt
│   │   └── repositories
│   │       ├── interfaces
│   │       │       └── (I)DBFooRepository.kt
│   │       └── JpaFooRepository.kt
│   └── monitorenv/monitorfish/rapportnav
└── 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.
• Config : on ne pourrait pas avoir un dossier "global" config plutôt ? C'est un peu hors clean-archi non ?
• 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 ce dossier intermédiaire ?
• 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 ?
• Exceptions : la séparation domain / infrastructure n'est pas clair.

Suggestions

• Nommage :
  • On suffixe tous les fichiers par leur rôle à l'exception des :
    • entities
    • enums
    • types
    • 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 ?).
• Exceptions :
  • Dans la mesure du possible, les exceptions qui proviennent de l'infrastructure avant de passer par le domain, normalement dans un use case, devraient être converties en une domain exception. Ce qui permet de conserver les exceptions infrastructure séparées de exception domain. Le global exception handler controller gérerait nominativement que les exceptions domain et via un "catch-all" les exceptions infrastructure non-gérée/transformée comme des erreurs internes 5xx.