Skip to content

PrΓ©sentation technique des applications

Ivan Gabriele edited this page Apr 24, 2024 · 31 revisions

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
β”‚   β”‚       └── ControllersExceptionHandler.kt
β”‚   β”œβ”€β”€ 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 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.
  • DTOs : on les garde bien dans les use cases ?

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.
    • ControllersExceptionHandler ne gΓ¨re nominativement que les exceptions domain.
    • Pour les exceptions infrastructure qui remontent jusqu'au ControllersExceptionHandler, cela signifie qu'elles sont non-gΓ©rΓ©es/non-transformΓ©es et sont donc des erreurs internes => 5xx. ControllersExceptionHandler les gΓ¨re via un "catch all".

Ce qui donnerait :

β”œβ”€β”€ config # All configs, both for domain & infrastructure.
β”‚   └── FooConfig.kt
β”œβ”€β”€ domain
β”‚   β”œβ”€β”€ entities
β”‚   β”‚   β”œβ”€β”€ foo
β”‚   β”‚   β”‚   └── Foo.kt
β”‚   β”‚   └── Utils.kt # Example for entities-dedicated utils, all functions in the same file.
β”‚   β”œβ”€β”€ exceptions # Only domain exceptions.
β”‚   β”‚       └── FooException.kt
β”‚   β”œβ”€β”€ filters
β”‚   β”‚       └── FooFilter.kt
β”‚   β”œβ”€β”€ mappers
β”‚   β”‚       └── FooMapper.kt
β”‚   β”œβ”€β”€ repositories
β”‚   β”‚   └── (FooRepository
β”‚   └── use_cases
β”‚       └── foo
β”‚           β”œβ”€β”€ dtos
β”‚           β”‚   └── FooDto.kt
β”‚           └── CreateOrUpdateFoo.kt # Include methods suffixed by API version if necessary.
β”œβ”€β”€ infrastructure
β”‚   β”œβ”€β”€ api
β”‚   β”‚   β”œβ”€β”€ adapters
β”‚   β”‚   β”‚   β”œβ”€β”€ bff
β”‚   β”‚   β”‚   β”‚   └── foo
β”‚   β”‚   β”‚   β”‚       β”œβ”€β”€ CreateOrUpdateFooDataInput.kt
β”‚   β”‚   β”‚   β”‚       └── FooDataOutput.kt
β”‚   β”‚   β”‚   └── publicapi
β”‚   β”‚   └── endpoints
β”‚   β”‚       β”œβ”€β”€ bff
β”‚   β”‚       β”‚   β”œβ”€β”€ FooController,kt
β”‚   β”‚       β”‚   └── BarController.kt # Include methods suffixed by API version if necessary.
β”‚   β”‚       β”œβ”€β”€ publicapi
β”‚   β”‚       └── ControllersExceptionHandler.kt # Handle domain exceptions, catch-all infra exceptions.
β”‚   β”œβ”€β”€ database
β”‚   β”‚   β”œβ”€β”€ models
β”‚   β”‚   β”‚   └── FooModel.kt
β”‚   β”‚   β”œβ”€β”€ queries
β”‚   β”‚   β”‚   └── FooQueryRepository.kt
β”‚   β”‚   └── repositories
β”‚   β”‚       └── JpaFooRepository.kt
β”‚   β”œβ”€β”€ exceptions # Only infrastructure exceptions.
β”‚   β”‚       └── FooException.kt
β”‚   └── monitorenv/monitorfish/rapportnav
└── utils # Global utils, one file per function.
    └── GlobalFooer.kt

Frontend

Structure et nommage des fichiers

β”œβ”€β”€ components/                                   # Components shared between multiple features.
|   β”œβ”€β”€ ProjectComponent.tsx
β”œβ”€β”€ features/
|   β”œβ”€β”€ Menu/
|   |   β”œβ”€β”€ components/
|   |   |   β”œβ”€β”€ MainWindowRightMenu/
|   |   |   |   β”œβ”€β”€ index.tsx
|   |   |   β”œβ”€β”€ SideWindowMenu/
|   |   |   |   β”œβ”€β”€ index.tsx                     # Import `ProjectComponent.tsx`.
|   └── Vessel/
|       β”œβ”€β”€ components/
|       |   β”œβ”€β”€ VesselButton.tsx
|       |   β”œβ”€β”€ VesselAdministrationTable/
|       |   |   β”œβ”€β”€ Row
|       |   |   |   β”œβ”€β”€ constants.ts
|       |   |   |   β”œβ”€β”€ Label.tsx
|       |   |   |   β”œβ”€β”€ index.tsx                 # Import `ProjectComponent.tsx` & `VesselButton.tsx`.
|       |   |   β”œβ”€β”€ index.tsx
|       |   β”œβ”€β”€ VesselListDialog/
|       |   |   β”œβ”€β”€ Item
|       |   |   |   β”œβ”€β”€ constants.ts
|       |   |   |   β”œβ”€β”€ index.tsx                 # Import `VesselButton.tsx`.
|       |   |   β”œβ”€β”€ index.tsx

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