DDD

Archi & techno

Devoxx 2013 : La mort de l’UPDATE ?

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…

Lire la suite
Archi & techno

CQRS, l’architecture aux deux visages (partie 2)

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…

Lire la suite
Archi & techno

CQRS, l’architecture aux deux visages (partie 1)

Two players. Two sides.

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…

Lire la suite
Archi & techno

Domain Driven Design : des armes pour affronter la complexité

"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…

Lire la suite