DDD à l'échelle de l'entreprise?

Question

Vous cherchez des suggestions sur la façon d'aborder ce problème et de comprendre si Domain Driven Design est vraiment le meilleur modèle ici.

Mon client est en train de re-architecturer sa pile d'outils et de services presque obsolète. Le client est un e-marchand en expansion rapide. Son produit principal est son grand site Web de commerce électronique. Autour de ce site, le client dispose d'une variété de flux de données qu'il expose à ses partenaires. Une foule d'applications internes pour aider dans le marketing, les ventes, les rapports, etc. Une foule d'applications de soutien aux utilisateurs et de soutien aux partenaires. Une bonne quantité de différentes synchronisations de données, travaux ETL, etc ... Vous obtenez l'image.

Les magasins de données et les fournisseurs de données sont également nombreux. Le stockage méga-évolutif basé sur le nuage NOSQL fournit la plupart des choses sur le site Web public. Les serveurs SQL avec un certain nombre de bases de données fournissent des données aux applications internes. Il existe également des serveurs spéciaux de recherche uniquement pour fournir des capacités de recherche mégascalables, ainsi que d'autres flux que les applications consomment auprès de divers fournisseurs tiers. Si DDD est adopté, le plan consisterait à hériter de différents groupes d'objets de référentiel à partir de classes de base de référentiel spécifiques à un magasin de données

Le client a exécuté un exercice dans lequel il a cartographié la plupart de ses entités métier sur une base de données. niveau "générique": noms et relations d'entités. En dehors de ce niveau "générique", il y a une quantité décente de réutilisation de divers objets concrets à travers les applications ainsi qu'une quantité décente d'entités qui différeraient dans leur implémentation, en fonction d'une application.

Par exemple: entité Commander sur un site de commerce électronique peut ressembler à X, alors que pour une application qui gère les appels de soutien tels que Y, et de plus pour quelqu'un de faire une analyse de la fraude comme Z.

Je cherche des suggestions sur comment adapter DDD ou un autre modèle architectural pour gérer ce désordre géant: avoir une stratégie d'entreprise solide qui facilite la réutilisation et permet la séparation de la logique si nécessaire. En plus des critères habituels (évolutifs, flexibles, adaptables, unit-testables, simples, etc.).

En raison de différents magasins de données, la structure des DTO est très différente de celle du magasin de données au magasin de données. En raison de divers besoins commerciaux, diverses applications ont besoin de différentes versions de certaines entités, et comme l'entreprise est en pleine expansion, l'avenir est très instable et la flexibilité est primordiale. Je suppose que mon plus gros problème est de trouver un moyen de séparer le modèle d'affaires à différents domaines et de le maintenir ensemble quand il y a beaucoup de partage ou de réutilisation, tout en étant capable d'adopter un niveau élevé de changement.

Merci pour toutes vos suggestions

P.S. La boutique est un magasin Microsoft. VS2010/.NET/SQL/Azure

Answer 1

SOA + Considérez DDD

Sur la surface il semble que vous devriez considérer l'architecture orientée services (SOA) avec Domain Driven Design (DDD). Quelque chose dans le style de NServiceBus.

Udi Dahan a une superbe vidéo sur DDD + NServiceBus ici:

• http://www.udidahan.com/2010/06/18/cqrs-ddd-and-nservicebus-video/

DDD est sur l'isolation de votre logique métier *

DDD à son noyau est isolant votre logique de domaine à partir de votre application et de votre infrastructure afin de vous assurer que vous modélisez correctement la logique métier. DDD n'est pas pour tous les projets, il n'est définitivement pas adapté aux petites entreprises où le coût de maintenance de DDD est plus élevé que les avantages que vous en retirerez.

Dans votre cas

Vous avez décrit un ensemble de règles d'affaires assez complexe qui l'OMI bénéficiera fortement de DDD. Je voudrais cependant aussi vous amener à considérer un SOA qui peut vous permettre d'intégrer plusieurs architectures dans un cadre d'entreprise au moyen d'un système de messagerie universel.

utilisant SOA

• http://www.udidahan.com/2009/02/07/nservicebus-19/

NServiceBus est une messagerie puissante, mais léger, open source cadre pour la conception des systèmes d'entreprise distribués .NET. Entièrement facile à utiliser, NServiceBus donne aux programmeurs une longueur d'avance sur le développement de couches de services robustes, évolutives et maintenables et de processus métier de longue durée.