Re: Show me the code

Ne prends pas ombrage de ses remarques. Toi même tu demandes un feedback. Je souscris à pas mal de ses remarques sauf une:
celle qui semble insinuer qu'un autodidacte ne saurait fournir du code de qualité. Et je ne vais pas m'embarquer dans ce débat.

Tu appelle à un retour, tu sembles attaché à la qualité de la documentation. Je te cite:

Pas de tutoriel ? Pas d’exemple ? Next !

Bien nommer
Si vous ne savez pas noter une variable, une classe, une fonction, c’est qu’elle n’a pas a exister de la façon d’où vous la pensez.

Pourtant lorsqu'on t'objecte certains point tu sembles mal le prendre. Je suis d'accord que la forme importe mais il me semble que ton contradicteur est resté courtois.

Je me suis aussi un peu penché sur ton code et je m'exprime peut-être à tort, je ne connais pas le framework Play donc je peux raconter des bêtises.
Tu appelles aux contributions et pourtant tu ne documentes pas ton architecture, tes conventions de codage... Tu ne laisses rien qui puisse permettre de l'appréhender. Qu'à cela ne tienne, en lisant ton journal, on pourrait se dire que l'on a affaire à un adepte du "Clean code" (Je t'invite vraiment à lire http://www.amazon.fr/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) et que la lumière se fera au travers lui. Comme évoqué par quelqu'un plus haut, un des avantages à disposer de tests est que ceux-ci représentent un forme de spécifications et aident à mieux comprendre le code de production (le Sytem under Test). Tu n'en disposes pas. Soit ...

Mon habitude, personnellement dans ce genre de cas, pour comprendre de quoi ça parle, c'est de découvrir le domaine: les classes métiers.
Si j'en juge par la description de Play! On a bien affaire un framework MVC (https://www.playframework.com/documentation/1.4.x/main#mvc). A priori, tu l'as adopté entre autre parce qu'il est bien documenté.
Lorsque je me penche sur tes modèles voici ce que j'y découvre:
https://github.com/hdsdi3g/MyDMAM/tree/master/app/models
Des profils utilisateur, des ACLs.
Que fait ton appli ? Je me renseigne donc sur ce qu'est un DMAM ...
Je m'attendais à trouver des entités "Média", "Utilisateurs" et bien d'autres ... et il faut fouiller dans ce fourre-tout que tu as nommé "hd3gtv" pour trouver un semblant de classe métier comme ce qui aurait pu s'appeler "MetaData": https://github.com/hdsdi3g/MyDMAM/blob/master/app/hd3gtv/mydmam/metadata/MetadataCenter.java

Si on se penche sur un de tes rares modèles https://github.com/hdsdi3g/MyDMAM/blob/master/app/models/UserProfile.java
J'ai l'impression qu'on se trouve devant un problème d'affectation des responsabilités.
Par exemple, que vient faire une méthode comme celle-ci là au milieu ?

private static String cleanFileName(String value)
A t'elle un sens métier ?
Si elle n'est utile que pour d'autre méthodes de la classe pourquoi n'est elle pas privée ?
Si tu la rends publique, c'est donc que tu considères que c'est la responsabilité d'autres classes de formater correctement l'email d'un profil utilisateur ?
Sinon pourquoi ne pas l'isoler dans une classe utilitaire si tu considère qu'elle pourrait être réutilisable ?

Je n'évoquerai pas ces contrôleurs à qui (me semble t'il) tu confies la tâche de persister certaines de tes données.

Je ne te parlerai même pas d'injection des dépendances dont je ne trouve pas trace et qui hormis la testabilité t'apporte une vraie liberté pour "refactorer" ton code, comme tu l'évoques si bien en te permettant de changer d'implémentation de manière très souple.

Encore une fois ne prends pas ombrage, mais cette profusion de méthodes statiques sont le signe d'une conception très procédurale (qu'un autre l'a appelé de l'an 2000).
J'ai l'impression que tu n'as pas saisi certains des concepts fondamentaux du paradigme de programmation orientée objet.
Je t'encourage à approfondir ces concepts et le plus important d'entre eux l'encapsulation qui veut que les données et les traitement et les données sont regroupées et qui confère un avantage sur le procédural. Avant de partir sur les design patterns du Gof comme tu l'évoquais, tu devrais peut-être faire un petit détour par les patterns de responsabilité, les fameux GRASP: https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

Et pour finir je te reparlerai de ce "modèle de domaine anémique" qu'on rencontre parfois et que j'ai déjà évoqué plus haut.
En général, on le reconnait à des entités qui ne disposent d'aucune logique métier et ne sont que des passe plat à base getter et setter.
Le tien, je ne sais pas comment le qualifier à part que j'ai l'impression qu'il est inexistant ou dilué (encore une fois je peux me tromper). Mais tu n'es pas obligé de me croire.
C'est pourquoi je t'invite une nouvelle fois à te pencher sur la documentation du framework que tu as adopté.
Il y est fait une mention explicite au lien sur Martin Fowler que je t'ai pointé plus haut:
https://www.playframework.com/documentation/1.2/model

A common Java anti-pattern is to keep the model as a set of simple Java Beans and put the application logic back into a "service" layer which operates on the model objects.

Martin fowler again has named this anti-pattern Anemic object model

Si j'ai pris la peine de rédiger cette longue bafouille ce n'est pas pour te faire la leçon mais au contraire pour t'encourager à poursuivre ton cheminement dans une direction peut-être trop consensuelle pour toi mais qui permettrait vraiment d'ouvrir ton code aux contributions autrement que par la licence. Tu as déjà fait une belle partie du chemin seul, ne t'arrête pas au milieu du gué.