Concevoir une application

La méthode de découpage : des écrans et des fonctionnalités vers les composants et les messages. Son cœur est une doctrine de granularité : ne pas multiplier les composants ni les messages.

Quatre règles

1. Un composant = une fonction cohérente, jamais une action ni un widget

Découpe par fonction et/ou déploiement. Un agrégat de une à trois tables liées, toujours lues et écrites ensemble, fait un composant serveur. Une zone fonctionnelle (une vue et ses contrôles) fait un composant client. À l'intérieur, programmez normalement.

Deux morceaux méritent d'être deux composants seulement si l'une de ces questions reçoit « oui » : pourraient-ils être déployés séparément ? l'un est-il réutilisable ou affichable indépendamment de l'autre ? ont-ils des cycles de vie ou des responsabilités franchement différents ? Sinon, un seul.

2. Un message = une capacité, regroupée par oneOf

gerer_clients: {
	versions: { 1: { revisions: { 0: {
		oneOf: ["read", "create", "update", "delete"],
		fields: {
			read:   { type: "object", fields: { filtre: { type: "object", required: true, fields: { nom: { type: "string" } } } } },
			create: { type: "object", fields: { client: { type: "object", required: true, fields: {
				nom:   { type: "string", required: true },
				email: { type: "string", required: true, pattern: "^[^@]+@[^@]+$" },
			} } } },
			update: { type: "object", fields: { id: { type: "number", required: true }, patch: { type: "object", required: true, fields: {} } } },
			delete: { type: "object", fields: { id: { type: "number", required: true } } },
		},
	} } } },
	examples: { 1: { 0: [ { read: { filtre: {} } }, { create: { client: { nom: "Acme", email: "a@b.co" } } }, { delete: { id: 42 } } ] } },
	counterexamples: { 1: { 0: [ { reason: "aucun membre oneOf", payload: {} }, { reason: "deux membres oneOf", payload: { read: { filtre: {} }, delete: { id: 42 } } } ] } },
},

À fuir : lire_clients, creer_client, maj_client, suppr_client. On note un couple gerer_clients.read. Séparer en messages distincts seulement si les opérations ont des abonnés différents, des cycles de vie disjoints ou une frontière de déploiement différente : la requête et sa réponse sont deux messages.

3. L'authentification se branche sur cette granularité

session.allowMessage = (name, payload) => {
	const user = session.data.user;
	if (!user) return name === "login";
	if (name === "gerer_clients" && payload.delete) return user.role === "admin";
	return true;
};

4. Les résultats aussi : un message de retour, ciblé

this.broker.publish(this, { clients_result: { ok: true, rows }, id: message.id });

Tableau des anti-patterns

La procédure, à partir d'une spécification

1. Inventorier

   Les données (tables) et les fonctionnalités (actions, écrans, règles d'accès).

2. Regrouper les données en agrégats

   De 1 à 3 tables liées. Un agrégat = un composant serveur.

3. Un message d'opérations par agrégat

   gerer_<agrégat> avec un oneOf, et un <agrégat>_result ciblé.

4. Tracer les frontières client/serveur

   Ce qui doit être relocalisable devient un composant plus un message de transit, déclaré partagé et autorisé au canal.

5. Côté client, un composant par zone fonctionnelle

   Pas par widget.

6. Poser l'authentification

   Un composant serveur abonné à login écrit session.data.user ; au connected, il installe allowMessage.

7. Écrire les catalogues, puis les composants

   Avec examples et counterexamples.

8. Contrôle final

   Chaque message a un émetteur et au moins un abonné ; aucun couple de composants ne se distingue par un nom d'instance ; le nombre de composants et de messages reste proportionné. Sinon, re-regroupez.

Exercice guidé : le chat

Exercices à faire seul