Des écrits concrets sur les concepts que nous enseignons — de la conception d'agrégats aux stratégies de test. Sans superflu, sans remplissage, juste les idées qui comptent en production.
Vous pensez qu'il suffit de créer une classe statique et d'y ajouter une méthode factory pour obtenir un Factory Method ? Alors vous passez à côté de toute la subtilité de ce pattern. Voyons ça ensemble.
Saviez vous que if n'existe pas en Smalltalk, l'ancêtre des langages objets ? On pourrait croire que c'est par fainéantise ou que c'est une lubie d'illuminés de la Silicon Valley, mais la réalité est bien plus profonde..
Dans le développement orienté objet, il est courant de se retrouver avec des hiérarchies de classes. Et tôt ou tard, on finit par implémenter une sous-classe qui n'a pas besoin de toutes les méthodes de la super classe.
Il existe un lien subtil entre les patterns Iterator et Visitor. En un sens, l'un est même une généralisation de l'autre : le premier est homogène, le second hétérogène.
Quand on découvre le Domain-Driven Design, surtout à travers les livres récents, on commence souvent par enseigner le design stratégique, à savoir identifier le Domain et les Subdomains, et décomposer son application en Bounded Contexts.
Un bon moyen de saisir la notion de Bounded Context est de se projeter dans la vision orienté-objet qu'on se faisait d' un Domain Model à l'époque où l'OO n'était pas encore mature.
Si vous êtes familier avec le domain-driven design, vous avez certainement soupé du Invariant Métiers et de l'importance des Aggregates dans leur modélisation. Seulement, modéliser un invariant métier dans un aggregate n'est pas toujours simple.
Comment tester les requêtes paginées ?
Qu'est-ce que le pattern Ports & Adapters ? Quel intérêt ? Pourquoi s'en servir ? Et surtout, qu'est-ce que ça coûte ?
