DDD

Afin de pallier aux problèmes des architectures N-tiers, plusieurs alternatives ont émergé après les années 2000, dont l’architecture Hexagonale et la Clean architecture. Seulement, elles ne sont pas toujours bien comprises : pour expliquer l'une, certains utilisent parfois les termes de l'autre ; d’autres se basent sur des croyances plutôt que sur les publications d'origine. Et si nous comparions ces deux architectures pour lever le doute une fois pour toutes ? Les concepts d’architecture hexagonale et de clean architecture sont parfois mélangés ou mal compris.…

Nous avons souvent dans nos modélisations, nos schémas, nos user stories, nos bases de données et nos APIs un petit champ nommé status, parce que l'anglais ça fait classe. Et bien je vous le dis tout de bon, ce petit champ qui stocke le statut de votre ressource, il sent mauvais et augure bien des périls, en particulier si vous pouvez le modifier. Il peut être révélateur d'une perte de richesse fonctionnelle de notre solution ainsi que de défauts de cohérences ou de résilience de la conception…

Après trois jours de Devoxx où j'ai assisté à de nombreuses présentations il me semble identifier une tendance forte pour l'avenir de notre profession. J'ai assisté à des conférences très différentes sur des sujets très variés. Elles ont un point commun. Nous sommes à un jalon de notre profession. Nous ne travaillerons pas demain comme aujourd'hui. En effet, nous devrons trouver des solutions à un nouveau challenge : comment gérer l'augmentation des volumes à traiter sans pouvoir augmenter la puissance des traitements ? La réponse…

Dans le billet CQRS l’architecture aux deux visages (partie 1), nous vous avions présenté les bases d’une architecture CQRS. En effet une application combine des fonctionnalités de consultation d’une part (Read) et traitement métier d’autre part (Write). CQRS propose d’aborder ces deux groupes de fonctionnalités comme deux contextes d’utilisation distincts afin d’appliquer des stratégies de design adaptées à leurs besoins spécifiques. Dans cet article, nous allons essayer d’apporter des réponses à la question laissée en suspens : comment construire une application satisfaisant aux exigences liées au contexte de…

Dans un article précédent, nous avons vu comment l’approche DDD, via la définition et l’utilisation d’un Ubiquitous Language et d’un véritable modèle du domaine, peut faciliter la communication entre acteurs projet, aider à l’écriture d’un code plus expressif (et donc plus maintenable), et capable d’adresser la complexité - et les changements - du métier. Aujourd’hui, nous allons essayer de répondre à certaines questions laissées en suspens par notre première approche de DDD. Comment éviter de multiplier les couches de mapping, sans valeur ajoutée, à différents…

"La complexité, c'est comme le cholestérol. Il faut surtout se débarasser du mauvais." (Proverbe gascon-malgache) DDD est l’acronyme de Domain Driven Design. Ce n’est ni un framework, ni une méthodologie, mais plutôt une approche décrite dans l’ouvrage du même nom d’Eric Evans. Un de ses objectifs est de définir une vision et un langage partagés par toutes les personnes impliquées dans la construction d’une application, afin de mieux en appréhender la complexité. Nous ne souhaitons pas faire ici une présentation de DDD (voir plutôt ici…