Dans ce billet, Lea Verou explore l’idée que le succès d’un produit dépend de la manière dont il gère l’effort demandé à l’utilisateur en fonction de la complexité des cas d’usage. Elle illustre ce principe avec plusieurs exemples : Google Calendar, qui optimise les cas simples tout en permettant les cas complexes avec un effort supplémentaire ; l’élément HTML <video>, où la personnalisation des contrôles devient soudainement très coûteuse en effort ; l’éditeur Instagram, qui sépare les filtres prédéfinis des réglages avancés ; et Coda, qui intègre intelligemment des formules générées automatiquement pour faciliter la transition entre simplicité et complexité. Elle souligne aussi l’importance de concevoir des interfaces qui minimisent l’effort utilisateur, même si cela complique l’implémentation, comme le montre l’exemple des robinets ou des bornes de train d’Oslo. L’article plaide pour une courbe d’effort progressive, évitant les « falaises d’utilisabilité » où un petit besoin supplémentaire exige un effort démesuré. En résumé, un bon design doit être une « bonne affaire » pour l’utilisateur, pas une arnaque.
L'article explore une approche pour construire des applications en combinant les principes du Domain-Driven Design (DDD) et de l'architecture Clean. L'auteur propose de se concentrer sur les cas d'utilisation plutôt que sur les entités pures du DDD, en utilisant des cas d'utilisation pour orchestrer la logique métier inter-aggregats de manière claire et ciblée. L'article présente un exemple d'application simple avec des entités comme Student et Course, illustrant comment modéliser le domaine et gérer les relations entre les agrégats. Il préconise l'utilisation de l'ORM pour les opérations C(r)UD et des requêtes JDBC directes pour les requêtes impliquant plusieurs agrégats, s'inspirant des principes CQRS. Les cas d'utilisation sont transactionnels pour garantir la cohérence des états des agrégats. L'article conclut en soulignant les avantages de cette approche, notamment une meilleure compréhension du code et une facilité de test.
Tout est dans le titre
Un article passionnant sur le process de création d'un produit et la balance entre spécialisation (qui mène à l'overfitting) et la généralisation (pas toujours implémentable)