Modélisation d'un modèle de domaine faiblement couplé

Question

La question ne concerne pas vraiment DDD mais souhaiterait savoir s'il existe un moyen de modéliser un modèle de domaine faiblement couplé. Qu'est-ce que je veux dire par là? Je travaille pour un éditeur de logiciel RH et nous prévoyons de commencer une nouvelle application à partir de zéro. Nous avons fait une vérification de tous les projets que nous avons réalisés pour nos 150 clients et le fait est que nous ne pouvons pas dire qu'il existe un modèle de domaine valide du point de vue de DDD.

Pourquoi? Parce que chaque entreprise traite les RH de différentes manières selon la taille de l'entreprise, etc.

Bien sûr, nous pouvons identifier les entités communes dans le domaine des ressources humaines comme: emploi, offre, collaborateur, compétences, etc., mais elles sont pas lié de la même manière pour le client A et le client B. Donc, du point de vue du modèle de domaine, nous ne pouvons pas dire que l'entité A a une référence à l'entité B qui a une collection de compétences car elle ne sera pas vrai pour un autre client.

Même si pour 80% de nos clients nous pouvons concevoir un modèle qui répond à 90% des besoins, nous ne sacrifierons pas le reste des clients et d'un autre côté voudrions avoir un produit avec un développement spécifique pour adresser différentes préoccupations.

Nous avons examiné les solutions BPM, mais cela ne correspond pas à nos besoins. D'un autre côté, je ne peux pas imaginer comment vous pouvez gérer ce dont nous avons besoin. En fait, les liens entre les entités doivent être "fait" à l'exécution à partir d'une sorte de paramètre, xml, etc. pour chaque client. Nous aimerions ne pas avoir à coder une autre application car le modèle de domaine a légèrement changé. Cela pourrait être complètement fou de ne pas avoir un modèle de domaine propper, mais quelque chose basé sur la messagerie pourrait nous aider.

Aimeriez-vous votre avis à ce sujet. Comment avez-vous géré ces situations?

Merci,

Answer 1

Le but d'un modèle de domaine est d'encapsuler les comportements et les relations communs. Bien que vous puissiez (et devriez) coupler votre implémentation, il y a des limites à la façon dont vous pouvez la configurer.

Si vous continuez à pousser vers de plus en plus de configurabilité, à un certain point, il cessera d'être un modèle de domaine et deviendra à la place un Framework. Vous pouvez ensuite utiliser le Framework pour définir des modèles de domaine spécifiques.

Écrire un Framework est vraiment, vraiment difficile, donc je ne pense pas que ce soit un plan réalisable pour démarrer un projet avec cet objectif explicite. Si vous le pouvez, commencez avec une base de code commune et chaque fois que vous obtenez une requête spécifique au client, refactorisez le noyau afin de pouvoir implémenter la fonction client comme plugin.

Avec beaucoup de temps , la chance et la compétence, vous peut pouvoir évoluer ce noyau dans un cadre spécifique du domaine .

Answer 2

« La question de produit magique », nous sommes tous à la recherche d'un de ces :). Je viens de faire un avec succès en utilisant SOA. Nous avons fait un bon travail en identifiant les services et plus tard nous avons juste changé un peu les orchestations ou les services aux entreprises. Ce que j'essaie de dire est que vous ne serez jamais capable d'aborder toutes les différences par configuration, je devrais mettre l'effort de faire un bon code en pensant à une adaptabilité facile, mais, à mon humble avis, le "produit magique" est impossible.