it-swarm.com.de

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

Ich erstelle eine RESTful-Lösung für .NET 4.5 C # Web API und möchte, dass mir jemand mitteilt, ob meine Projektlösung für eine mit Domain Driven Design entwickelte Lösung korrekt und/oder sinnvoll (-genug?) 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 das Sammeln von Werten aus Anforderungsobjekten und das Bitten der BizApi-Ebene um Arbeit.

  • /Biz.Api

(Referenziert von Base])

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

  • /Biz.Domain

(Referenziert von Biz.Api)

Stellt die Domänenklassen für die Biz.Api-Ebene bereit. Diese bieten Methoden zum Bearbeiten der Daten des Unternehmens im Speicher.

  • /Dal.Db

(Referenziert von Biz.Api)

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

  • /Dal.Services

(Referenziert von Biz.Api)

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

  • / Schnittstellen

(Von den meisten Projekten oben referenziert)

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

15
Matt W

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

Lösung:
├ WebService (REST Services befinden sich hier)
├ WebServiceTests
├ Anwendung (Anwendungsdienste befinden sich hier)
├ Anwendungstests
├ Domain (Entitäten, VO, Domänendienste, Domänefabriken, Spezifikationen, Domänenereignisse, Repositorys-Schnittstellen, Schnittstellen für Infrastrukturdienste)
├ DomainTests
├ Infrastruktur (Repositorys, implizite Infrastrukturdienste, Adapter für externe Dienste)
└ Infrastrukturtests

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

Erstellen Sie in Ihrer Domänenschicht keinen Ordner interfaces oder services, sondern verwandte Klassen sollten nach Funktionen in Modulen gruppiert werden.

22
Songo

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

Im "internen DTO" -Teil kann es jedoch zu einem Geruch kommen, da Sie Entitäten aus Repositorys entfernen und Domänen- (Geschäfts-) Aktionen direkt auf sie ausführen sollen. Entitäten sind nicht nur DTOs.

Ich versammle mich irgendwie aus der Tatsache, dass Dal.Db hat keine Abhängigkeit von Biz.Domain, dass die Domänenschicht eine Zuordnung zwischen DTOs aus dem Interfaces-Projekt (von Repositorys zurückgegeben?) und ihren eigenen Domänenobjekten vornimmt. Dies wäre in einer typischen DDD-Architektur nach dem Stand der Technik (== "Zwiebel" oder "sechseckig") nicht korrekt - die Domänenschicht sollte nicht auf andere Projekte verweisen. Aus dem gleichen Grund sollten Repository-Schnittstellen in der Domäne und nicht in Interfaces deklariert werden, wie ich denke.

1
guillaume31