DDD и реализация настойчивости

Я впервые начинаю понимать DDD (в.Net), так как перестраиваю некоторые основные компоненты унаследованного корпоративного приложения.

Я хочу кое-что прояснить: как мы реализуем постоянство в правильной архитектуре DDD?

Я понимаю, что домены сами по себе являются невежественными и должны разрабатываться с использованием "вездесущего языка" и, конечно, не должны ограничиваться ЦАП месяца или даже физической базой данных.

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

Откуда вызываются мои настоящие методы репозитория (CRUD)?

Источник

3 ответа

Решение

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

Да, это очень хороший подход.

Откуда вызываются мои настоящие методы репозитория (CRUD)?

Это может быть хорошей идеей, чтобы не думать в терминах CRUD, потому что это слишком ориентировано на данные и может привести вас к общей ловушке репозитория. Хранилище помогает управлять серединой и концом жизни для доменных объектов. Фабрики часто ответственны за начало. Имейте в виду, что когда объект восстанавливается из базы данных, он находится на стадии среднего возраста с точки зрения DDD. Вот как может выглядеть код:

// beginning 
Customer preferredCustomer = CustomerFactory.CreatePreferred();
customersRepository.Add(preferredCustomer);

// middle life
IList<Customer> valuedCustomers = customersRepository.FindPrefered();

// end life
customersRepository.Archive(customer);

Вы можете позвонить этот код прямо из вашего приложения. Возможно, стоит скачать и посмотреть пример DDD Эвана. Паттерн " Единица работы" обычно используется для обработки транзакций и абстрагирования вашего ORM по вашему выбору.

Источник

Проверьте, что Стив Болен должен сказать по этому вопросу. Код для презентации можно найти здесь.

Я был на презентации и нашел информацию о том, как правильно моделировать репозитории.

Источник

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

Я не согласен, скажем, система состоит из следующих слоев:

  • Уровень представления (формы win, веб-формы, asp.net MVC, WPF, php, qt, java, ios, android и т. Д.)
  • Бизнес-уровень (иногда называемый менеджерами или сервисами, логика здесь идет)
  • Уровень доступа к ресурсам (вручную или ORM)
  • Ресурс / Хранилище (RDBMS, NoSQL и т. Д.)

Здесь предполагается, что чем выше вы, тем более изменчивый уровень (самый высокий - это представление, а самый низкий - это ресурс / хранилище). Именно из-за этого вы не хотите, чтобы уровень доступа к ресурсам ссылался на бизнес-уровень, а наоборот! Бизнес-уровень ссылается на уровень доступа к ресурсам, вы вызываете DOWN, а не UP!

Вместо этого вы помещаете интерфейсы / контракты в их собственную сборку, они вообще не имеют смысла на бизнес-уровне.

Источник
Другие вопросы по тегам