Ist dies eine gute Visual Studio-Lösungsstruktur für einen REST-fähigen Webdienst mit domänengesteuertem Design?

Ich erstelle eine .NET 4.5 C # Web-API-REST-Lösung und möchte, dass jemand mir mitteilt, ob meine Projektlösung für eine mit Domain Driven Design entworfene Lösung korrekt und / oder sinnvoll (-genügend?) Ist.

Die Lösung wurde in 6 Projekte aufgeteilt:

• /Base

(Von nichts referenziert)

Das Webprojekt und bildet die Schnittstelle zwischen der Lösung und der Außenwelt. Enthält die Web-API-Controller. Enthält fast keine Logik, außer Werte von Anforderungsobjekten zu erfassen und die BizApi-Ebene um Arbeit zu bitten.

• /Biz.Api

(Referenziert von Base)

Stellt die Domänendienste bereit und ermöglicht dem Schnittstellenprojekt / Base den Zugriff auf die Geschäftslogikobjekte der Domäne im Projekt /Biz.Domain.

• /Biz.Domain

(Referenziert von Biz.Api)

Stellt die Domänenklassen für die Biz.Api-Ebene bereit. Diese bieten Methoden zum Bearbeiten der Geschäftsdaten im Arbeitsspeicher.

• /Dal.Db

(Referenziert von Biz.Api)

Die Datenbank-Repository-Schicht. Greift auf die Datenbanken zu und ordnet die zurückgegebenen Daten internen DTOs zu, die in der Ebene / Interfaces definiert sind.

• /Dal.Services

(Referenziert von Biz.Api)

Stellt eine Proxy-Ebene für externe Abhängigkeiten wie Webdienste bereit und ordnet die zurückgegebenen Daten internen DTOs zu, die im Projekt / Interfaces definiert sind.

• / Schnittstellen

(Von den meisten oben genannten Projekten referenziert)

Enthält die DTO-Klassen zum Weitergeben von Daten in der Lösung und die C # -Schnittstellen zum Definieren von Verträgen für Dinge wie IoC.

Diese Ordnerstruktur ist inspiriert von dem berühmten Implementing Domain Driven Design Book von Vaugh Vernon.

Lösung:
├ WebService ^{_{(REST Services befinden sich hier)}}
├ WebServiceTests
├ Anwendung ^{_{(Application Services befinden sich hier)}}
├ ApplicationTests
├ Domain ^{_{(Entities, VO, Domain - Services, Domain Fabriken, Spezifikationen, Domain - Veranstaltungen, Repositorys Schnittstellen, Infrastruktur - Services - Schnittstellen)}}
├ DomainTests
├ Infrastruktur ^{_{(Repositories, Infrastructure Services Impl., Adapter auf externe Services)}}
└ InfrastructureTests

Ich beginne mit einer Lösung, erstelle dann vier Projekte für jede Ebene in meiner Anwendung und teste dann weitere vier Projekte für jede Ebene.

Erstellen Sie keinen Ordner interfacesoder servicesin Ihrer Domänenebene, stattdessen sollten verwandte Klassen nach Funktionen in Modulen gruppiert werden.

Was die Struktur angeht, scheint es mir in Ordnung zu sein, obwohl ich mir andere, selbsterklärendere Namen ausgedacht hätte, wie zum Beispiel "YourProjectWebApi"anstelle von "Base", "Dal.External"anstelle von "Dal.Services"und so weiter.

Es kann jedoch ein Geruch im "internen DTO" -Teil auftreten, da Entitäten aus Repositorys entfernt werden sollen und Domänen- (Geschäfts-) Aktionen direkt auf sie angewendet werden können. Entitäten sind nicht nur DTOs.

Ich gehe von der Tatsache aus, dass die Domain-Schicht Dal.Dbkeine Abhängigkeit davon hat, Biz.Domain,dass sie eine Zuordnung zwischen DTOs aus dem Interfaces-Projekt (von Repositories zurückgegeben?) Und ihren eigenen Domain-Objekten vornimmt. Dies wäre in einer typischen DDD-Architektur nach dem Stand der Technik (== "Zwiebel" oder "Sechseck") nicht korrekt - die Domänenschicht sollte nicht auf andere Projekte verweisen. Aus dem gleichen Grund sollten Repository-Schnittstellen in der Domäne deklariert werden und nicht so, Interfaceswie ich es denke.