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,

Odpowiedzi:

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