#domain-driven-design #ddd-repositories
#дизайн, управляемый доменом #ddd-репозитории
Вопрос:
Я только начал углубляться в свои первые эксперименты с дизайном доменных дисков и использую преимущества шаблона NWorkspace. Этот шаблон, похоже, имеет большой смысл, однако я не смог найти очень много примеров мест, где этот шаблон был успешно использован или даже публично задокументирован. Прежде чем я перейду к моей реализации, я хотел бы знать, добился ли кто-нибудь успеха с использованием этого шаблона или может ли кто-нибудь указать мне на какие-либо ссылки, где NWorkspace использовался в любом проекте с открытым исходным кодом, у которого я мог бы поучиться. Также существуют ли лучшие или более известные альтернативы этому шаблону, о которых я должен знать?
Краткая информация о NWorkspace
Для тех, кто, возможно, не знаком с NWorkspace, это шаблон, представленный Джимми Ниссоном, который абстрагирует обязанности по обработке запросов и сохранению. В своей книге «Применение дизайна и шаблонов, управляемых доменом» Джимми Нильссон показывает, как NWorkspace можно использовать для абстрагирования инфраструктурных частей репозитория DDD, а также предоставляет механизм для обеспечения атомарности между репозиториями в отношении сохраняемости.
Ответ №1:
Похоже, он рекомендует отдельные интерфейсы для репозиториев чтения и записи.
У меня нет опыта работы с описанным шаблоном, но я бы рекомендовал не проводить транзакции между репозиториями. Вместо этого я бы предложил несколько решений, популярных среди сообщества DDD (Эрик Эванс, Уди Дахан, Грег Янг), которые действительно помогли мне:
- Всегда используйте ускоренную загрузку в своих корнях aggregate. Тогда вам не нужна атомарность между репозиториями, и выяснить, что изменилось при сохранении объекта, намного проще.
- Используйте отдельные классы для записи (т. Е. классы домена) и чтения (т. Е. вашу viewmodel). Создайте репозитории view model, которые извлекают viewmodels непосредственно из базы данных (вместо сопоставления объектов домена для просмотра классов моделей).
Посмотрите, упрощает ли реализацию вышеуказанных двух вещей ваш дизайн.
Комментарии:
1. Второе предложение кажется мне немного чуждым, звучит почти так, как будто ViewModel обрабатывается как совокупный корень. Не могли бы вы указать мне на какие-либо ресурсы, которые обсуждают это подробнее? Я не смог найти много текущих обсуждений по DDD, кроме небольшого здесь, о переполнении стека, поэтому любые другие ресурсы были бы очень полезны.
2. Конечно. Главные парни, о которых вы хотите прочитать, — это Уди Дахан и Грег Янг. У них есть видеовыступления на skillsmatter.com это настоятельно рекомендуется. Также ознакомьтесь cqrsinfo.com. Метод, который я описываю в # 2 выше, называется CQRS (разделение ответственности за командный запрос). Он был изобретен вышеупомянутым Грегом Янгом.
3. Основная идея CQRS заключается в том, что классы вашего домена (по крайней мере, общедоступные) в основном представляют собой методы без общедоступных установщиков и с небольшим количеством общедоступных получателей. Все чтение выполняется через viewmodel, которые в значительной степени являются общедоступными средствами получения и настройки.
4. Интересно, я обязательно изучу эти темы. Я слышал о CQRS довольно давно, я использовал его в качестве руководящего принципа при разработке методов, но идея уменьшения объема, в котором модель домена действует как хранилище данных, поддерживающее ViewModel, имеет смысл, хотя я не уверен, как это влияет на важность самого домена. Таким образом, в принципе, если модель домена вызывается только для целей записи, у нее ограниченный срок службы, и, следовательно, большую ее часть можно записать в виде цепочки вызовов методов вместо моделирования домена объектно-ориентированным способом… Ну, это только мои первоначальные мысли.
5. Преимущество, вероятно, станет очевидным для вас, когда вы начнете сталкиваться с разногласиями с тем, что вам нужно в пользовательском интерфейсе (например, если вам нужны данные из 2 агрегатов в одной сетке) по сравнению с тем, как вы хотите моделировать поведение домена. Это не было очевидно для меня, пока я не приобрел больше опыта.