Инфраструктурные услуги DDD
просто опубликуйте где-нибудь свой экземпляр регистратора. тем путем другие модули и клиенты могут использовать Ваш API для получения регистратора, не имея необходимость к import multiprocessing.
4 ответа
Если придерживаться определений DDD, репозиторий отличается от службы. Репозиторий напрямую связан с сущностью, часто с агрегированным корнем. Служба определяет поведение, которое на самом деле не принадлежит ни одной сущности в вашем домене. Вы можете найти службы на каждом уровне, хотя типы проблем, которые они решают, различаются от уровня к уровню и могут отличаться от концептуальной службы DDD.
При работе на концептуальном уровне репозиторий DDD отличается от службы DDD тем, что он специально привязан к сохранению сущности. Служба может решить любую проблему домена, приложения или инфраструктуры, которая может у вас возникнуть.
Вы постоянно сталкиваетесь с терминологическими противоречиями с DDD. Например, репозиторий DDD - это НЕ то же самое, что шаблон репозитория , найденный в Мартине Фаулере. s PoEAA, хотя в ней может использоваться такой шаблон. Это часто является источником путаницы для многих.
В DDD помогает, если вы всегда держите модель предметной области в самом центре всего, что вы делаете. Когда доходит до наслоения приложений DDD, я часто выбираю Луковую архитектуру Джеффри Палермо . Проверить это. Загрузите CodeCampServer , пример приложения, использующего эту архитектуру. Я думаю, это идеально подходит для программирования DDD.
Удачи!
пример приложения, использующего эту архитектуру. Я думаю, это идеально подходит для программирования DDD.Удачи!
пример приложения, использующего эту архитектуру. Я думаю, это идеально подходит для программирования DDD.Удачи!
К сожалению, в DDD есть слово «Сервис». Это должно быть «Доменная служба». Думайте о Домене как о сущностях и объектах значений, тогда как Сервисы - это способ работы с действиями, операциями и действиями.
Что касается репозиториев, они всего лишь фасад, который должен вести себя как коллекция для вашего домена. Если вы используете ORM или пишете свой собственный, это то, через что должны пройти все ваши объекты домена, чтобы добиться постоянства вместо этих служб напрямую.
Зачем вы помещаете реализации репозитория в инфраструктуру? Они вообще не имеют отношения к «Инфраструктуре» imho.
Согласно Синей книге Эвана , репозитории являются частью модели предметной области. Поэтому я поместил интерфейс репозитория в модель предметной области. Реализация репозитория также иногда.
Инфраструктура должна содержать код «инфраструктуры», который может быть услугой, которая позволяет вам легко отправлять электронную почту через smtp, или кодом, который абстрагирует доступ к БД для вас (так, некоторые классы которые вы могли бы использовать в своем репозитории, но это не ваш репозиторий).
Итак, не помещайте свои репозитории в «инфраструктуру», поскольку они там не принадлежат. Для меня классы, которые можно найти в инфраструктуре, - это классы, которые вы можете использовать в разных других проектах, понимаете, что я имею в виду? Классы, которые не связаны тесно с вашей моделью предметной области или приложением, принадлежат Infrastructure. И реализация репозитория довольно тесно связана с конкретным приложением. :)
Возможно, это поможет увидеть потенциальную структуру проекта.
Возможная структура сборки или пакета:
Project.Domain
Project.Infrastructure.Data
Project.Infrastructure.Components
Проект .Infrastructure.Services
Возможное пространство имен или структура папок:
Project.Domain
- n- Modules
---- n- Account
{ {1}} ------- f- Account.xx
------- f- AccountRepository.xx
------ -f- Contact.xx
---- n- Маркетинг
------- f- RegionRepository.xx
- n- Общие
- n- Услуги
Project.Infrastructure.Данные (OR-Mappers)
- n- Таблицы
- n- Представления
- n- Процедуры
-n- Функции
Project.Infrastructure.Components (Generic)
- n- Mail
- n- Криптография
- n- UI
Project.Infrastructure.Services (специальные операции)
- f- DoingSomethingService1.xx
- f- DoingSomethingService2.xx
- f- DoingSomethingService3.xx
Объекты домена и типы значений не используют доменные службы. Уровень приложений использует службы домена. Объекты репозитория домена используют объекты Infrastructure.Data для возврата объектов домена.