Czy to dobra struktura rozwiązania Visual Studio dla usługi internetowej RESTful opartej na domenie?

15

Buduję .NET 4.5 C # Web API RESTful rozwiązanie i chciałbym, aby ktoś mi powiedział, czy moje rozwiązanie projektu jest poprawne i / lub mądre (-wystarczy?) Dla rozwiązania zaprojektowanego przy użyciu Domain Driven Design, proszę.

Rozwiązanie zostało podzielone na 6 projektów:

/Baza

(Niczego nie ma)

Projekt internetowy stanowi interfejs między rozwiązaniem a światem zewnętrznym. Zawiera kontrolery Web API. Nie zawiera prawie żadnej logiki poza zbieraniem wartości z obiektów żądania i proszeniem warstwy BizApi o pracę.

/Biz.Api

(Referenced by Base])

Zapewnia usługi domenowe i umożliwia projektowi interfejsu / Base dostęp do obiektów logiki biznesowej domeny w projekcie /Biz.Domain.

/Biz.Domain

(Odwołany przez Biz.Api)

Udostępnia klasy domen dla warstwy Biz.Api. Zapewniają one metody manipulowania danymi firmy w pamięci.

/Dal.Db

(Odwołany przez Biz.Api)

Warstwa repozytorium bazy danych. Dostęp do baz danych i map zwróconych danych do wewnętrznych DTO zdefiniowanych w warstwie / Interfejsy.

/Dal.Services

(Odwołany przez Biz.Api)

Zapewnia warstwę proxy do zewnętrznych zależności, takich jak usługi sieciowe, i odwzorowuje ich zwrócone dane na wewnętrzne DTO zdefiniowane w projekcie / Interfaces.

/ Interfejsy

(Odwołanie w większości projektów powyżej)

Zawiera klasy DTO do przesyłania danych wokół rozwiązania oraz interfejsy C # do definiowania umów na rzeczy takie jak IoC.

c# rest domain-driven-design

— Matt W.
źródło

„/Biz.Api świadczy usługi domenowe”: masz na myśli usługi aplikacyjne? Ponadto repozytoria zazwyczaj nie zwracają DTO, ale jednostki (zagregowane katalogi główne).

— Warto

Tak, mam na myśli usługi aplikacji. Repozytoria zwracają instancje klas, które jedynie przechowują dane - dane te są mapowane na instancję przy użyciu, w tym przypadku, AutoMapper. Zwrócona instancja nie ma żadnych metod manipulacyjnych, które, jak uważam, mają Encje.

— Matt W

„te dane są zmapowane”: między czym a czym? Co rozumiesz przez „manipulowanie metodami”?

— guillaume31,

22

Ta struktura folderów została zainspirowana słynną książką projektową Vaugh Vernon opartą na domenie Implementing .

Rozwiązanie:
├ WebService ^{_{(REST Usługi rezydują tutaj)}}
├ WebServiceTests
├ aplikacji ^{_{(Application Services rezydują tutaj)}}
├ ApplicationTests
├ Domain ^{_{(Podmioty, VO, usługi domenowe, fabryki domen, specyfikacje, imprezy domen, interfejsy Przechowalnie, infrastruktura usługi interfejsy)}}
├ DomainTests
├ Infrastruktura ^{_{(repozytoria, usługi infrastrukturalne, adaptery do usług zewnętrznych)}}
└ ^_Testy infrastruktury

Zaczynam od Rozwiązania, następnie tworzę cztery projekty dla każdej warstwy w mojej aplikacji, a następnie kolejne cztery projekty dla każdej warstwy testowej.

Nie twórz folderów interfacesani servicesw swojej warstwie domeny, zamiast tego pokrewne klasy powinny być pogrupowane według funkcji w modułach.

— Songo
źródło

1

Jeśli chodzi o strukturę, wydaje mi się to w porządku, chociaż wymyśliłbym inne, bardziej samoopisujące nazwy, takie jak "YourProjectWebApi"zamiast "Base", "Dal.External"zamiast "Dal.Services"i tak dalej.

W części „wewnętrzny DTO” może wyczuć zapach, ponieważ powinieneś wydobywać jednostki z repozytoriów i móc bezpośrednio na nich podejmować działania domenowe (biznesowe). Podmioty to nie tylko DTO.

W pewnym sensie czerpię z faktu, że Dal.Dbnie ma zależności od Biz.Domain,tego, że warstwa domeny wykonuje pewne mapowanie między DTO z projektu Interfejsy (zwrócone przez repozytoria?) A własnymi obiektami domeny. Nie byłoby to poprawne w typowej najnowocześniejszej (== „cebulowej” lub „heksagonalnej”) architekturze DDD - warstwa domeny nie powinna odwoływać się do innych projektów. Z tego samego powodu interfejsy repozytorium powinny być deklarowane w domenie, a nie w, Interfacesjak sądzę, są.

— guillaume31
źródło