Domain Driven Design : partie 2

Dans la première partie on a vu à quoi servait le DDD, le nommage des classes, découper son projet en Bounded Context et comment les Aggregates peuvent séparer les responsabilités.

Comment faire pour éviter que notre projet ne se transforme en une usine à gaz ?

Si on avait une règle à retenir ça serait celle-ci :

Un cas d’utilisation = une transaction = un aggregate

Domain Driven Design : Partie 1

Domain Driven Design c’est essentiellement une question de nommage. On nomme énormément de choses dans notre code, mais de quelle manière ? et pourquoi ?

Pour ceux qui aiment la programmation orientée objet, on modélise très vite notre model en un diagramme de classe. On donne un nom générique à chaque classe et c’est plié.

Pourtant quand on commence un nouveau projet, on nous donne un contexte, un domaine sur lequel nous reposer. Si on doit proposer un catalogue de vélo ou de voyages, on va utiliser des mots et des termes différents. Cependant, notre code lui va rester sensiblement le même.