Dans l?approche Domain Driven Design, le c?ur de la solution c?est le domaine métier. Du point technique le domaine est en général une assembly centrale qui est référencée par toutes les couches qui gravitent autour du domaine (repository, service, infra, UI, tests unitaires et fonctionnels). Cette dépendance forte est souvent montrée du doigt par certains collègues pro active record et qui pensent que les données c?est 90% du business. Et la question qui pose est : "Souvent" le client est amené à faire évoluer ses process et à mettre à jour son métier, dans ce cas il faut refaire toute l?application à cause de cette dépendance. En général je réponds que normalement le client change rarement de processus et que le c?ur du métier est toujours le même, donc l?évolution à apporter dans le modèle n?est pas importante, et en général c?est l?infrastructure qui change (base de données, fichiers, Service web ? ) et ca on sait gérer, si l?implémentation des infras sont facilement injectables. Mais admettant que le client revoit ses process et son c?ur de métier tout les mois ? que faire ? Je suis allé chercher une réponse hier dans la présentation animée par Sebastien Ros au sujet de l?Adaptative Object Model. Et je me suis rendu compte que faire du « DDD adaptable » c?était faisable : En DDD on manipule des entités qui ont des propriétés, des relations avec d?autres entités, des value type, et contient des comportements qui encapsule la logique métier. Il suffit donc de faire une méta description des éléments de base pour monter et manipuler un domaine : un customer par exemple est une instance de meta type entité qui a les propriétés suivantes : FirstName, LastName, Address, et une liste de commande. Son comportement se résume ainsi : s?il a déjà dépensé 500 euros, il a droit à 10% de remise sur sa prochaine commande. Au-delà des objets du domaine, on peut aussi automatiser la création des repositories si une entité est marquée par l?attribut « root agregate » ? Imaginons que c?est faisable, et imaginons qu?une société A a racheté une société B, et imaginons que société A et B on déjà des domaines adaptables (utilisation de l?AOM dans une optique DDD). La mise en relation des systèmes d?information devient simple car il suffit de s?échanger les méta-descriptions respectives de leurs domaines et enfin d?appliquer des règles de transformation. Par exemple : Pour la société A, un customer possède les propriétés : AddressLine, ZipCode, Country et pour la société B un Customer a la propriété Address. La règle à introduire côté société B est : Address = AddressLine + ZipCode + Country. Toutes ces règles sont au niveau des méta-descriptions et sont facilement échangeable : Ficher XML par exemple. Mieux encore, si l?on met en place un monitoring des fichiers de méta-description on peut automatiquement mettre à jour les règles d?adaptation au sein des sociétés s?interfaçant avec le système.
dotnetlogue
