Est-ce une bonne structure de solution Visual Studio pour un service Web RESTful de conception pilotée par domaine?

Je crée une solution RESTful d'API Web CNET .NET 4.5 et j'aimerais que quelqu'un me dise si la solution de mon projet est correcte et / ou judicieuse (-assez?) Pour une solution conçue à l'aide de Domain Driven Design, s'il vous plaît.

La solution a été divisée en 6 projets:

• /Base

(Pas référencé par quoi que ce soit)

Le projet web et forme l'interface entre la solution et le monde extérieur. Contient les contrôleurs d'API Web. Ne contient presque aucune logique au-delà de la collecte de valeurs à partir des objets de demande et de la demande de travail à la couche BizApi.

• /Biz.Api

(Référencé par Base])

Fournit les services de domaine et permet au projet d'interface / Base d'avoir accès aux objets de logique métier de domaine dans le projet /Biz.Domain.

• /Biz.Domain

(Référencé par Biz.Api)

Fournit les classes de domaine pour la couche Biz.Api. Ceux-ci fournissent des méthodes pour manipuler les données de l'entreprise en mémoire.

• /Dal.Db

(Référencé par Biz.Api)

Couche de référentiel de base de données. Accède aux bases de données et mappe les données retournées dans les DTO internes définis dans la couche / Interfaces.

• /Dal.Services

(Référencé par Biz.Api)

Fournit une couche proxy aux dépendances externes telles que les services Web et mappe leurs données retournées aux DTO internes définis dans le projet / Interfaces.

• / Interfaces

(Référencé par la plupart des projets ci-dessus)

Contient les classes DTO pour transmettre des données autour de la solution et les interfaces C # pour définir des contrats pour des choses comme l'IoC.

Cette structure de dossiers est inspirée du célèbre livre de conception basé sur le domaine de l'implémentation de Vaugh Vernon.

Solution:
├ WebService ^{_{(REST résident ici)}}
├ WebServiceTests
├ application ^{_{(services d'application résident ici)}}
├ ApplicationTests
├ Domaine ^{_{(Entités, VO, les services de domaine, les usines de domaine, les spécifications, les événements de domaine, interfaces Référentiels, les infrastructures de services interfaces)}}
├ DomainTests
├ Infrastructure ^{_{(référentiels, implémentation de services d'infrastructure, adaptateurs aux services externes)}}
└ InfrastructureTests

Je commence par une solution, puis je crée quatre projets pour chaque couche de mon application, puis quatre autres projets pour chaque couche.

Ne créez pas de dossier interfacesou servicesdans votre couche de domaine, mais les classes associées doivent être regroupées par fonctionnalité dans les modules.

En ce qui concerne la structure, cela me semble OK, même si j'aurais trouvé des noms différents et plus auto-descriptifs, comme au "YourProjectWebApi"lieu de "Base", "Dal.External"au lieu de "Dal.Services"et ainsi de suite.

Cependant, il peut y avoir une odeur dans la partie "DTO interne", car vous êtes censé retirer les entités des référentiels et être en mesure de prendre des actions de domaine (métier) directement sur elles. Les entités ne sont pas seulement des DTO.

Je Dal.Dbcomprends en quelque sorte du fait que cela n'a aucune dépendance Biz.Domain,que la couche Domain fait un mappage entre les DTO du projet Interfaces (retourné par les référentiels?) Et ses propres objets Domain. Cela ne serait pas correct dans une architecture DDD de pointe typique (== "oignon" ou "hexagonal") - la couche Domaine ne devrait pas référencer d'autres projets. Pour la même raison, les interfaces de référentiel doivent être déclarées dans le domaine et non pas Interfacescomme je suppose qu'elles le sont.