Услуги DDD Infrastructure

Ответ 1

При использовании определений DDD репозиторий отличается от службы. Репозиторий напрямую коррелирует с сущностью, часто сводным корнем. Служба определяет поведение, которое на самом деле не принадлежит одному объекту в вашем домене. Вы можете абсолютно найти Сервисы на каждом уровне, хотя типы проблем, которые они адресуют, отличаются от уровня к слою и могут отличаться от концептуального сервиса DDD.

При работе на концептуальном уровне репозиторий DDD отличается от службы DDD тем, что он определенно привязан к постоянству Entity. Служба может обращаться к любой проблеме домена, приложения или инфраструктуры, которую вы можете иметь.

Вы столкнулись с конфликтами терминологии с DDD повсюду. Например, репозиторий DDD - это не то же самое, что шаблон хранилища, найденный в книге Мартина Фаулера PoEAA, хотя он может использовать такой шаблон. Это часто является источником путаницы для многих людей.

Это помогает с DDD, если вы всегда держите модель домена в самом центре всего, что вы делаете. Когда дело доходит до слоев DDD-приложений, я часто выбираю Jeffrey Palermo Onion Architecture. Проверьте это. Загрузите CodeCampServer, пример приложения, использующего эту архитектуру. Я думаю, что это идеально подходит для DDD-программирования.

Удачи!

Ответ 2

Несчастная вещь в DDD - это слово "Сервис". Должно быть, это "Служба домена". Подумайте о домене как объектах и ​​объектах ценности, в то время как Сервисы - это способ решения действий, операций и действий.

Что касается репозиториев, это просто фасад, который должен вести себя как коллекция в вашем домене. Если вы используете ORM или пишете свое собственное, это то, что должны пройти все объекты вашего домена, чтобы добиться персистентности вместо этих служб.

Ответ 3

Возможно, это поможет увидеть потенциальную структуру проекта.

Возможная сборка или структура упаковки:

Project.Domain
Project.Infrastructure.Data
Project.Infrastructure.Components
Project.Infrastructure.Services

Возможное пространство имен или структура папок:

Project.Domain
-n- Модули
---- n- Учетная запись
------- f- Account.xx
------- f- AccountRepository.xx
------- f- Contact.xx
---- n- Маркетинг
------- f- RegionRepository.xx
-n- Общие
-n- Услуги

Project.Infrastructure.Data(OR-Mappers)
-n- Таблицы
-n- Просмотры
-n- Процедуры
-n- Функции

Project.Infrastructure.Components(общий)
-n-Mail
-n- Криптография
-n- UI

Project.Infrastructure.Services(Специальные операции)
-f- DoingSomethingService1.xx
-f- DoingSomethingService2.xx
-f- DoingSomethingService3.xx

Сущности домена и типы значений не используют службы домена. Уровень приложения использует службы домена. Объекты репозитория домена используют объекты Infrastructure.Data для возврата объектов домена.

Ответ 4

Зачем вы добавляете реализации репозитория в инфраструктуру? Они не связаны с "Инфраструктурой" на всех имхо. Я в основном помещал интерфейсы репозитория в "модель домена", и я поместил реализацию этих репозиториев в модель домена.

Инфраструктура должна содержать код "инфраструктуры", который может быть сервисом, который позволяет вам легко отправлять электронную почту через smtp или код, который абстрагирует доступ к БД для вас (так, некоторые классы, которые вы могли бы использовать в своем репозитории, но это не ваш репозиторий).

Итак, не помещайте свои репозитории в "инфраструктуру", так как они там не принадлежат. Для меня классы, которые можно найти в инфраструктуре, являются классами, которые вы можете использовать в других проектах, понимаете, что я имею в виду? Классы, которые не тесно связаны с вашей моделью или приложением домена, относятся к инфраструктуре. Реализация хранилища довольно тесно связана с конкретным приложением.:)