Inroduction

Un projet informatique, c’est une implémentation d’une solution à un problème souvent occurrent dans la vraie vie, puisqu’il intègre un certain niveau d’automatisation, de performance et/ou de rapidité dans l’implémentation.

Un problème qui vient exactement domaine applicatif (métier) de notre système.

Comme dans toute science exacte, il faudrait comprendre les problématiques pour pouvoir apporter la solution. Les équipes de développement de logiciels se trouvant face à des domaines complexes ne peuvent pas faire cela.

C’est de là que vient l’approche de “conception centrée buisness domaine” appelée DDD ou Domain driven Design. Elle se base sur le domaine du métier et propose ce que Eric Evans appelle “un framework pour prendre des décisions de conception en utilisant un vocabulaire technique”.

Dans ce document, nous décrirons la démarche pour faire du DDD sur des projets informatiques, étape par étape à partir de la compréhension du domaine et jusqu’à la finalisation de la conception en utilisant les patterns proposées par cette approche.

Mais qu’en est il des microservices, et surtout du lien entre le DDD et les microservices ?

Dans ce document aussi, nous allons évoquer l’utilité du faire un DDD dans une implémentation microservices, et cela à deux niveaux:

• À un premier niveau, dans chaque étape de l’approche DDD, nous nous focalisons sur le côté utile du design pour faire un système en microservices.

• À un deuxième niveau, et après avoir compris concrètement de quoi il s’agit, nous commençons le raisonnement en essayant d’appliquer le DDD sur un pattern projet vide de microservices et en essayant d’imaginer les deux scénarios:

  1. Etre dans un cas de migration à partir d’un gros monolithique
  2. Commencer à partir du zéro en microservices