La conception pilotée par domaine est-elle utile / productive pour des domaines moins complexes?

Lors de l'évaluation d'un projet potentiel au travail, j'ai suggéré qu'il pourrait être avantageux d'utiliser une approche de conception pilotée par domaine pour son modèle objet. Le projet n'a pas de domaine excessivement complexe, donc mon collègue m'a lancé ceci:

Il a été dit que DDD est favorable dans les cas où il existe un modèle de domaine complexe («... Il s'applique chaque fois que nous opérons dans un domaine complexe et complexe» Eric Evans).

Ce que je perds, c'est - comment définissez-vous la complexité d'un domaine? Peut-il être défini par le nombre de racines agrégées dans le modèle de domaine? La complexité d'un domaine est-elle dans l'interaction des objets?

Le domaine que nous évaluons est la publication en ligne et la gestion de contenu connexes.

La complexité de la logique métier, également appelée comportement de l'application, est le facteur le plus important. Le deuxième facteur le plus important est l'écart entre le problème technique et le vocabulaire commercial utilisé pour décrire ce problème, car DDD consiste à créer un vocabulaire partagé entre l'entreprise et l'équipe d'ingénierie.

Certains des modèles utilisés dans DDD sont généralement utiles dans l'architecture des applications d'entreprise, tels que le modèle de référentiel, le contexte délimité et l'architecture en couches. Ce n'est pas parce que vous utilisez ces modèles que vous effectuez une conception basée sur le domaine.

S'il n'y a pas beaucoup de comportement, c'est-à-dire que vous stockez principalement des données et que vous n'agissez pas sur ces données, la création de cette couche de domaine peut avoir beaucoup moins de valeur. Dans la gestion de contenu, si tout ce que vous faites est d'approuver et de publier, cela peut être représenté par des indicateurs dans le système, plutôt que par des méthodes de domaine. Mais lorsque vous commencez à ajouter un comportement supplémentaire, la pertinence d'une couche de domaine complète devient plus apparente.

Si nous parlons de gestion de contenu, voici quelques règles (imaginées) qui pourraient commencer à faire allusion à la nécessité de DDD:

• Si l'article est sous embargo jusqu'à la date xx / yy / zz, publier sur papier, puis sur le Web; s'il n'y a pas d'embargo, publier sur le Web et mettre à disposition pour impression
• Rendez cette histoire disponible immédiatement derrière le paywall pour les abonnés payants; sortie au grand public 2 semaines plus tard.
• Après avoir écrit une histoire, envoyez-la à un éditeur pour révision, relecture et approbation. Une fois approuvé, envoyez-le en production. Si la production coupe l'histoire pour des raisons d'espace, rendez une version étendue disponible en ligne.