Skip to content

Latest commit

 

History

History
68 lines (44 loc) · 5.54 KB

decisions.md

File metadata and controls

68 lines (44 loc) · 5.54 KB

2019-04-06

  • Il me paraît naturel sémantiquement d'avoir l'utilisateur courant dans la request, je l'y place donc.
  • Nous commençons la création des routes employe/me/[ressources] qui fournit des opérations automatiquement filtrées sur l'utilisateur courant. La convention est de décrire ces routes dans le fichier dédié à la ressource (ie. employe/me/heure/repos dans /Tools/Route/Heure.php).

~ Prytoegrian

2018-12-17

  • Afin de mieux coller aux résultats de __DIR__ et dirname(), je supprime tous les slashes finaux des constantes *_PATH

~ Prytoegrian

2018-10-20

  • Il y a de multiples méthodes de connexion à l'application « libertempo » et l'API commence à les absorber petit à petit. Naturellement, j'ai souhaité que cette diversité de connecteurs soit transparente pour la plus grande partie de l'appli possible. J'ai donc mis en place une Fabrique pour que cette dernière fasse seule le choix du connecteur à sélectionner, ses consommateurs manipulant un contrat.
  • À cet effet, le contrôleur d'authentification n'est plus testable unitairement (le static l'en empêche). Je souhaiterais ne pas rester sur un échec et tester cette partie d'une autre manière.
  • Pour conserver la séparation stricte entre newable et injectable, j'ai de plus muté la Request serveur pour qu'elle contienne la configuration LDAP ; je ne suis pas trop fan de la solution et aimerais trouver une approche plus élégante et pérenne.

~ Prytoegrian

2018-06-07

  • J'ai désormais appliqué le paradigme « package by components » attendu que le « package by feature » soulevait des embûches. En effet, le contrôleur ne fait pas partie d'un composant, il est un moyen d'accès vers lui ; je l'ai donc déplacé dans Tools. À l'exception des répertoires d'utilitaires, nous aurons ainsi une vision claire des objectifs du logiciel du premier coup d'œil et une place toute trouvée pour les structures applicatives relatives au différents métiers du soft.
  • Un framework d'injection de dépendances a également fait son entrée. Il nous aidera à supprimer tout un pan de verbosité, facilite le test et nous permettra d'exprimer le plus précisément possible les interactions entre les structures applicatives.
  • Le problème des relations N-N n'en est pas encore un. Pour le moment, j'ai créé des entités pour les représentants de ces associations que l'on utilisera côté client. Si besoin il y a, nous créerons des Aggrégats.

~ Prytoegrian

2018-02-17

  • Dans le processus d'écriture de routes pour l'API, la table conges_groupe_resp fait apparaître une relation N-N ; problème, rien est encore fait dans ce sens et le « package par feature » nous ennuie un peu. Suivant la règle de 3 et le principe selon lequel on doit repousser les décisions importantes plus tard, je vise la simplicité et manipule l'entité « Utilisateur/UtilisateurEntite » suite à la requête. Quand nous en saurons plus on changera.

~ Prytoegrian

2017-11-04

  • À l'origine, j'avais mis les routes au pluriel car la sémantique était meilleure (avec GET /plannings, je veux la liste des plannings), mais l'idée atteint ses limites quand on se confronte à la langue (ex : journaux). Obliger à tenir une map serait inutilement lourd, aussi je vais au plus simple et je mets toutes les routes au singulier.

~ Prytoegrian

2017-09-12

  • Je renomme les modèles du design MVC en entités. Dans un contexte métier, la couche métier ne se résume pas à une seule classe et je ne veux pas perdre le lecteur en créant la confusion dans sa tête si une classe porte ce nom.

~ Prytoegrian

2017-09-24

  • Afin de suivre complètement Psr4, j'ai donné un préfixe au namespace global. Dans un contexte d'import, ça permet de bien séparer les packages. Ce faisant, \App devient inutile, je remonte donc tout d'un niveau

~ Prytoegrian

2016-10-29

  • Histoire de faciliter la transmission des connaissances et des intentions, j'amorce la création de ce fichier, en m'appuyant sur cette proposition.

  • Convaincu de la nécessité de séparer les responsabilités de l'application malgré une apparence de simplicité, je commence la création d'une API. L'un des risques qu'il pourrait y avoir est la dispersion et un ralentissement dans le processus de production, puisqu'il faut qu'un projet soit à jour pour que l'autre puisse avancer. Je suppose que ça ne sera vrai que le temps que l'API gagne en puissance.

  • Comme l'évoque cette issue, un framework permet de se concentrer sur son cœur de métier et d'avancer rapidement. Vu les besoins de l'API, Slim semble faire l'affaire. Le risque évident est la possibilité qu'il ne suffise pas aux besoins de l'application front et qu'on se retrouve avec deux framework. J'ai étudié les alternatives Lumen et Laravel, mais tous les frameworks semblent s'être pris d'amour pour le pattern ActiveRecord, qui est une horreur en terme de principe SOLID et je me refuse à coder ça...

  • Je tente quelque chose dans l'arborescence de fichiers. Bien que l'on suive le pattern MVC, je ne suis pas la traditionnelle arbo avec les répertoires Models - Views - Controllers. À mon sens, ce n'est pas ça que doit présenter l'arbo de premier abord. Une archi doit présenter l'intention de l'appli ; aussi, les unités de connaissances métiers sont mis en lumière, à l'instar de packages.

~ Prytoegrian