Some reviews

[mickaelwegerich]

Super, les gros concepts sont là 👍 :

• Ports/Adapters = injection de dépendance (découplage entre le coeur/core et le monde extérieur)
• Use case
• Domain

Je pense que le point qu'on peut améliorer c'est sur l'arborescence des répertoires. Je trouve qu'elle est trop orientée technique et non métier.
Du coup tu as des packages un peu partout, pour un petit truc j'ai eu un peu de mal à m'y retrouver (peut-être parce que je ne suis pas très java ?) mais quid sur des gros projets.
Ce que je propose (tu le verras dans ma vidéo), c'est de regrouper par grand ensemble métier ce qui peut s'apparenter à un bounded contexte en DDD, si tu connais (mais de très très loin) et dessous j'ai une arborescence qui est toujours la même (un peu plus technique).
Dans ton cas on pourrait avoir un truc du genre :

/application
/configuration (la config global du projet)
/user
   /adapters
     /primaries (on peut résumer à : ce qui afficher la donnée + action user)
       /controller
     /secondaries (on peut résumer à : ce qui manipule la donnée)
       /encoders
       /id-generators
       /repositories
      (des fois je re fais le distinguo entre real et in memory)
   /configuration (si tu as des trucs dédiés genre des routes API ou la DI pour cette ensemble)
   /domain
      /entities
      /exceptions
      /ports
      ...
   /usecases
     /validators

comme ça tout ce qui concerne les users est rangé au même endroit

---

Tu as super bien saisi dans tes use cases le découplage via les interfaces, je te propose d'aller un peu plus loin (peut-être un peu overkill pour juste une prez) et c'est plus du design.
C'est d'utiliser le Design Pattern Stratégie pour faire du CQS (command query separation), un exemple grossier du truc :

interface Query {
	List<User> handle(UserRepository userRepository);
	Optional<User> handle(UserRepository userRepository);
}

interface Command {
	void handle(UserRepository userRepository);
}

class UserHandler {
	private final UserRepository repository;
	public UserHandler(final UserRepository repository) {
		this.repository = repository;
	}
	List<User> query(Query query) {
		return query.handle(this.repository);
	}
	Optional<User> query(Query query) {
		return query.handle(this.repository);
	}
	void command(Command command) {
		command.handle(this.repository);
	}
}

class FindUserById implements Query {
	private String userId;
	public FindUserById(String userId) {
		this.userId = userId;
	}
	@Override
	public List<Optional<User>> handle(UserRepository userRepository) {
		return userRepository.findById(this.userId);
	}
}

// dans le code
new UserHandler().query(new FindUserById("1"));

Je rajoute une sorte de classe d'orchestration où juste elle connait mon répo par exemple, et plein de petites classes de manipulation de la donnée qui gravite autour (comme ce que tu as déjà fait).
Du coup ca me permet d'injecter uniquement cette classe et non toutes les petites classes, c'est ultra scalable et évolutif.

The end, je pense avoir fait le tour ;)

[carlphilipp]

Je pense que tu as raison, c'est plus clair de faire InMemoryUserRepository pour l'implementation de UserRepository (et aussi HazelcastUserRepository)

[carlphilipp]

je vais changer ca aussi

[carlphilipp]

Comment ca? La je suis dans l'app Spring, donc je me sers de Spring pour gerer mes dependencies

[mickaelwegerich]

Si en injectant les autres implémentations du même ports ici théoriquement ton appli devrait toujours fonctionner

[carlphilipp]

Oue ok je vois ce que tu veux dire. En fait j'utilise une implementation ici et l'autre implementation dans Vertx. Si j'injecte les deux ici, spring va utiliser la premiere qu'il trouve ou alors il faut preciser quel implementation utiliser. Je pense que j'expliquerais ca dans le post plutot que te surcharger le code

[carlphilipp]

Oui en Java on a les builder dans le pojo en general. Enfin d'habitude j'utilise Lombok https://www.projectlombok.org/features/Builder mais c'est pas encore compatible avec Java 10, du coup je l'ai fait a la main

[carlphilipp]

SPI = Serial Peripheral Interface Bus https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
J'avais trouve ca une fois quand je m'interessais a l'hexagonal architecture. J'aime bien car ca represente bien ce qu'est la classe, une interface/port a implementer. Apres je t'avoue ne pas l'avoir vu souvent. Je voulais eviter de creer un package par type comme tu le preconises, car dans mon example je risque d'avoir une classe par package. Enfin c'est tjrs le meme probleme de vouloir faire un example simple, mais proche de la realite, mais si c'est trop proche de la realite, ca devient plus compliquer a comprendre

[carlphilipp]

Yes, pas con, ca rendra les packages plus clair

[carlphilipp]

J'ai rename 30 fois les classes et les packages, c'est pour ca que un review etait necessaire ;)

je vais update le nom

[carlphilipp]

Oui en fait, je veux prouver qu'il est facil de changer l'implemention. A la base, je voulais faire un exemple in memory java simple + in memory DB (h2 ou mongo). Mais Java 10 est pas encore pret pour ce genre de truc, H2/JPA/Hibernate est pas vraiment encore compatible, donc le seul exemple simple que j'ai trouve c'est d'utiliser hazelcast

[mickaelwegerich]

yes bonne idée ;)
c'est un peu ce que je te propose dans le fichier application/spring-app/src/main/java/com/slalom/example/spring/config/Config.java