Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Agile Tour 2014 - Architecture Agile et développement durable

Publié par Félix-Antoine Bourbonnais le mardi 11 novembre 2014 à 00:00

Description

Beaucoup d’équipes ont embrassé Scrum sans considérer l’architecture nécessaire pour soutenir un tel rythme et minimiser la dette technique. Comment adopter une architecture émergente, malléable et facile à changer? Bref, comment faire du développement logiciel durable? Principes SOLID, patrons de conception d’entreprise, architecture émergente et pilotée par le domaine (DDD) sont au menu.

Présentation

Agile Tour 2014 - Les tests et la qualité: moteur de productivité

Publié par Félix-Antoine Bourbonnais, Pascal Roy le mardi 11 novembre 2014 à 00:00

Description

Comment transformer la qualité, les tests et le déploiement en moteur de productivité plutôt qu’en simple poste de dépenses? Portés par Lean et Agile, de grands acteurs (ex.: Google) ont transformé leur département d’assurance qualité pour le placer au coeur du processus de production! Limitez les tests réalisés après l’itération et diminuez la pression sur votre équipe qualité.

  • Présentateurs:  Félix-Antoine Bourbonnais et Pascal Roy
  • Niveau : Débutant
  • Public cible : Tous, spécifiquement Assurance qualité, gestionnaires et équipes de développement.

Présentation

DDD vs Clean Architecture: un trop court résumé...

Publié par Félix-Antoine Bourbonnais le jeudi 7 août 2014 à 00:00

DDD vd Clean Architecture

La semaine dernière, Anis Berejeb a publié un billet sur l’architecture par cas d’utilisation. Suite à mon commentaire, il y a eu un petit débat concernant la différence entre DDD (Domain-Driven Design) et Clean Architecture. La question portait surtout sur la place des cas d’utilisation (Jocobson) en DDD.

Mon commentaire se résumait à dire que la conception par les cas d’utilisation n’est pas la seule façon d’atteindre les objectifs de séparation de concepts, inversion des dépendances, séparation de la logique de la persistance et de l’affichage, etc.

Disons-le immédiatement, il est difficile de tracer une ligne claire, car DDD et Clean Architecture sont, sur plusieurs aspects, orthogonaux. Mais risquons-nous... 

La portée  

DDD est de plus haut niveau que Clean Architecture qui est plus technique. Ainsi, une bonne partie de Clean Architecture se trouve à être un moyen architectural, parmi d’autres, pour appliquer la philosophie DDD. 

DDD vise la modélisation de problèmes complexes dont la logique d’affaires est importante. DDD va aller toucher la modélisation du domaine et la communication avec des experts du domaine (établissement d’un langage commun, contextes ...). C’est donc beaucoup plus qu’un modèle architectural (technique), c’est aussi une philosophie de modélisation, voire une façon de réfléchir.

L’accent 

Dans l’approche, la principale différence en est une d’accent (focus) lors de la conception. CleanArchitecture focalise sur les cas d’utilisation alors que DDD focalise sur la modélisation du domaine (les entités, valeurs, …).

Ainsi, les praticiens de Clean Architecture semblent plus enclins à encapsuler les cas d’utilisation dans un « Interactor ». DDD risque de préférer intégrer les cas d'utilisation au domaine (dans les entités, Domain Service ...) puisque c’est là qu’est portée toute l'attention.

Où placer la logique

En CleanArchitecture la question sera possiblement: « est-ce indépendant de l’application? » La tendance sera donc d'en mettre plus dans « l’Interactor » et de mettre dans le modèle seulement ce qui est indépendant de manière évidente.

DDD a aussi le même concept (dépendant ou indépendant), mais aura tendance à poser la question à l’inverse en considérant d’abord le domaine, ce qui va avoir comme conséquence de placer d’avantage de code dans le domaine (notamment dans les entités) et de fragmenter le cas d’utilisation. DDD a aussi le concept du Bounded Context qui entrera en jeu dans cette décision en limitant les dérives de l'approche.

À l’inverse, Clean Architecture aura tendance à créer des entités avec moins de logique et d’en placer plus dans les « Interactors ». Évidemment tout cela est du cas par cas, mais on parle de tendance naturelle ici...

À noter qu’avec DDD, la couche d’Application Service en est une d’orchestration, mais pour les considérations plus techniques (ex.: les transactions) ou encore pour orchestrer sur plusieurs contextes (Bounded Contexts). On pourrait la voir comme une couche de cas d’utilisation, mais avec moins de détails (rappelez-vous que la définition et le découpage ne sont pas exactement pareils dans les deux approches).

Les services du domaine (Domain Service) auront aussi un rôle d’orchestration, mais pour ce qui ne peut être intégré à une entité.

Exemple 

Prenons l’exemple du paiement d’une commande illustré par ce graphique qui montre une conception plus orientée cas d’utilisation (Clean Architecture). En DDD, il serait plus probable de voir la méthode « payOrder » initialement placée dans l’entité « Order ». Cela ne veut pas dire que ça ne changerait pas dans le temps par contre. 

Pour un exemple en DDD, consultez le code de l’application DDD Samplecette formation en ligne ou encore le livre de Vaughn Vernon.

Avantages et inconvénients

Voici quelques avantages, inconvénients et risques naturels associés au «focus» différent. 

Quelques avantages de la modélisation par cas d’utilisation (Clean Architecture):

  • Cas d'utilisation identifiables facilement et clairement énoncés;
  • Facile de déployer les entités indépendamment et de les réutiliser dans plusieurs applications de l’entreprise (note: DDD a les concepts de Bounded Context et Shared Kernel pour balancer);
  • Plus facile de comprendre le cas d’utilisation rapidement.

Quelques risques:

  • Domaine moins structuré et plus « vide » ;
  • Réutilisation de la logique pour plusieurs cas d’utilisation plus complexe (ou dangereuse);
  • Danger de tomber dans un domaine anémique ou de faire de la programmation procédurale involontairement;
  • Danger de concevoir par les données les entités plutôt que d’avoir un domaine consistant représentant bien la logique du domaine d’affaires;
  • Moins d'outils concernant la manière d’arriver à modéliser son domaine, d’avoir un langage commun, etc;
  • Risque de complexité plus élevé dans « l’Interactor », plutôt que d’abstraire cette complexité dans le design du domaine.

 Et inversement pour DDD… Évidemment, comme toujours, tout est une question de compromis en fonction de son contexte. C’est ça l’art du développement logiciel !

Résumé et recommandations: complémentarité!

En résumé, tout est une question d’accent (focus). DDD focalise sur le domaine, CleanArchitecture sur les cas d’utilisation. Non pas que DDD ne considère pas les cas d’utilisation, mais ce n’est pas sur ça qu’est placé l'accent!

Si vous êtes dans un domaine de TI avec beaucoup de règles d’affaires, DDD vous sera probablement très utile pour modéliser le domaine, le découper, établir votre langage commun, etc. Vous pouvez certainement y combiner les techniques de Clean Architecture pour ce qui est de l’inversion des dépendances, de l’interfaçage, etc. 

À mon avis, l’important est de se souvenir qu’ils peuvent êtres complémentaires et que ce sont des techniques, pratiques et concepts à avoir dans sa trousse à outils. 

Donc comme le dit Bob Martin lui-même: « It's not really important which of the two [Use Case, Domain] drives […] It is the designers job, in each case, to prevent that muddle. » [2]. 

Après tout, les deux poursuivent le même but ultime! Tous s’entendent sur la nécessité de séparer la logique d’affaires des préoccupations techniques, l’inversion des dépendances, de rendre visible le domaine d’affaires plutôt que les frameworks et outils, etc.

Références 

[1] Comparaison selon Bob Martin:
https://groups.google.com/d/msg/clean-code-discussion/oEFEWq8qdFQ/i0gsi3eU5VoJ

[2] Lequel choisir selon Bob Martin:
https://groups.google.com/d/msg/clean-code-discussion/xm8QtaYwl3k/LWgFBs3erd0J

[3] Réponse connexe concernant l’application layer en DDD:
https://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/messages/24325

Présentation: Propulsez votre architectures grâce au TDD et aux Mocks (Agile Montréal 2014)

Publié par Félix-Antoine Bourbonnais le mercredi 12 mars 2014 à 06:00

Cette session a été présentée par Félix-Antoine Bourbonnais à la conférence mensuelle d'Agile Montréal le 12 mars 2014.

Description

Nous savons depuis longtemps que les tests automatisés jouent un rôle important pour les équipes de développement Agile. Bien que la communauté ait découvert depuis un certain temps des pratiques permettant de maximiser l’émergence du design via le TDD, il est rare que l’on présente des astuces concrètes pour obtenir ce bénéfice.

Cette présentation explique comment tirer le maximum de vos tests unitaires et des « mocks ». Nous présenterons, plus particulièrement, le style de TDD « mockiste ». Ainsi, nous verrons comment les mocks peuvent nous aider à concevoir une architecture ayant une meilleure conception orientée objet. 

  • Niveau : Avancé
  • Public cible : Développeurs et architectes

Présentation

 

Diapositives (PDF) 

Code source

 

Le code source de la démonstration est disponible pour téléchargement:
https://github.com/fbourbonnais/propulsez-architecture-tdd-mocks

 

Autres billets

 

Test unitaire: la définition qui lève les barrières

Publié par Félix-Antoine Bourbonnais le lundi 10 février 2014 à 00:00

Beaucoup d’entreprises où nous passons semblent avoir une définition des tests unitaires qui seraient mieux résumés, selon moi, par le terme “tests développeurs”.

On considère alors, à tort, un test unitaire comme étant un test effectué par les développeurs avant les tests “fonctionnels”. On les associe aussi souvent, de manière erroné, à un test des limites sur chacun des champs d’un écran.

Ce n’est pas l’unité dont on parle ici ! L’unité dans un test unitaire est la classe (le code) ! C’est donc un test d’un niveau bien plus bas qui n’impacte que le développeur...

Peu importe le nom, la clé est de comprendre que grâce à la technologie moderne, il est désormais possible d’avoir des tests qui opèrent directement au niveau du code (chaque classe individuellement). Il s’agit alors d’une responsabilité propre aux développeurs indépendants des analystes fonctionnels ou de la gestion.

Ce niveau très microscopique qui nous est offert par la technologie s’avère également être celui qui est le moins fragile (probabilité qu’un test soit impacté par beaucoup de changements dans le système) car il inspecte une zone très limitée (portée).

Voici la clé de la maintenabilité des tests...

Archive