Является ли это хорошей структурой решения Visual Studio для веб-службы RESTful, управляемой доменом?

15

Я создаю решение RESTful для .NET 4.5 C # Web API, и я хотел бы, чтобы кто-нибудь сказал мне, является ли мое проектное решение правильным и / или мудрым (достаточно?) Для решения, разработанного с использованием доменного дизайна, пожалуйста.

Решение было разделено на 6 проектов:

/База

(Ничего не указано)

Веб-проект и формирует интерфейс между решением и внешним миром. Содержит контроллеры Web API. Почти не содержит логики, кроме сбора значений из объектов запроса и запроса уровня BizApi для работы.

/Biz.Api

(Ссылка на базу])

Предоставляет доменные службы и позволяет проекту интерфейса / Base иметь доступ к объектам бизнес-логики домена в проекте /Biz.Domain.

/Biz.Domain

(Ссылка на Biz.Api)

Предоставляет доменные классы для слоя Biz.Api. Они предоставляют методы для манипулирования данными бизнеса в памяти.

/Dal.Db

(Ссылка на Biz.Api)

Уровень хранилища базы данных. Получает доступ к базам данных и отображает возвращенные данные во внутренние DTO, определенные на уровне / Interfaces.

/Dal.Services

(Ссылка на Biz.Api)

Предоставляет прокси-слой для внешних зависимостей, таких как веб-службы, и отображает их возвращенные данные во внутренние DTO, определенные в проекте / Interfaces.

/ Интерфейсы

(Ссылка на большинство проектов выше)

Содержит классы DTO для передачи данных вокруг решения и интерфейсы C # для определения контрактов для таких вещей, как IoC.

c# rest domain-driven-design

— Мэтт W
источник

«/Biz.Api Предоставляет доменные сервисы»: вы имеете в виду Application Services? Кроме того, хранилища обычно не возвращают DTO, а только сущности (совокупные корни). И о зависимостях между этими проектами тоже было бы полезно узнать;)

— guillaume31

Да, я имею в виду сервисы приложений. Репозитории возвращают экземпляры классов, которые ничего не делают, кроме хранения данных - эти данные отображаются в экземпляре с использованием, в данном случае, AutoMapper. Возвращенный экземпляр не имеет методов манипулирования, которые, как я понимаю, есть у сущностей.

— Мэтт W

«эти данные сопоставлены»: между чем и чем? Что вы подразумеваете под "манипулированием методами"?

— guillaume31

22

Эта структура папок навеяна знаменитой книгой Внедрения Версии, основанной на домене .

Решение:
├ WebService ^{_{(здесь находятся службы REST)}}
├ WebServiceTests
├ Приложение ^{_{(здесь находятся службы приложений)}}
├ ApplicationTests
├ Домен ^{_{(сущности, VO, доменные службы, доменные фабрики, спецификации, доменные события, интерфейсы репозиториев, интерфейсы сервисов инфраструктур)}}
├ DomainTests
├ Инфраструктура ^{_{(репозитории, включая инфраструктурные сервисы, адаптеры для внешних сервисов)}}
└ Инфраструктурные ^_тесты

Я начинаю с решения, затем создаю четыре проекта для каждого слоя в моем приложении, а затем еще четыре проекта для каждого слоя тестов.

Не создавайте папку interfacesили servicesслой вашего домена, вместо этого связанные классы должны быть сгруппированы по функциональности в модулях.

— Songo
источник

1

Что касается структуры, мне кажется, что все в порядке, хотя я бы придумал другие, более информативные имена, например, "YourProjectWebApi"вместо "Base", "Dal.External"вместо "Dal.Services"и так далее.

Однако во внутренней части DTO может быть какой-то запах, так как вы должны извлекать сущности из репозиториев и иметь возможность предпринимать действия с доменом (бизнесом) непосредственно над ними. Сущности не просто DTO.

Я как бы понял из того факта, что Dal.Dbон не зависит от Biz.Domain,того, что слой Domain выполняет какое-то отображение между DTO из проекта Interfaces (возвращаемого репозиториями?) И его собственными объектами Domain. Это было бы неправильно в типичной современной архитектуре DDD (== "onion" или "hexagonal") - уровень домена не должен ссылаться на другие проекты. По той же причине интерфейсы репозитория должны быть объявлены в домене, а не в том Interfacesвиде, в котором, я думаю, они находятся.

— guillaume31
источник