Repository, Service или Domain object - к чему относится логика?

Question

Возьмите этот простой, надуманный пример:

UserRepository.GetAllUsers (); UserRepository.GetUserById ();

Неизбежно, у меня будут более сложные «запросы», такие как:

//returns users where active=true, deleted=false, and confirmed = true
GetActiveUsers();

У меня проблемы с определением, где заканчивается ответственность хранилища. GetActiveUsers () представляет простой «запрос». принадлежит ли он в хранилище ?

Как насчет чего-то, что включает немного логики, например:

//activate the user, set the activationCode to "used", etc.
ActivateUser(string activationCode);

Answer 1

Репозитории отвечают за специфическую для приложения обработку наборов объектов. Это естественно охватывает запросы, а также набор изменений (вставка / удаление).

ActivateUser работает на одном объекте. Этот объект необходимо извлечь, а затем изменить. Хранилище отвечает за извлечение объекта из набора; другой класс будет отвечать за вызов запроса и использование объекта.

Answer 2

При создании проектов DDD мне нравится различать две обязанности: репозиторий и Finder.

Репозиторий отвечает за хранение агрегатных корней и их извлечение, но только за использование в обработке команд. Под обработкой команды я подразумевал выполнение любого действия, которое вызвал пользователь.

Средство поиска отвечает за запросы объектов домена для целей пользовательского интерфейса, таких как представления сетки и представления сведений.

Я не считаю искатели частью модели предметной области. Конкретные интерфейсы IXxxFinder размещаются на уровне представления, а не на уровне домена. Реализация IXxxRepository и IXxxFinder размещена на уровне доступа к данным, возможно, даже в одном классе.

Answer 3

Это все отличные вопросы. Возможность определить, какие из них следует использовать, зависит от вашего опыта и проблемы, над которой вы работаете.

Я бы предложил почитать книгу типа корпоративной архитектуры Фаулера . В этой книге он обсуждает шаблоны, которые вы упоминаете. Наиболее важно, хотя он назначает каждому шаблону ответственность . Например, логика домена может быть размещена либо на уровне службы, либо на уровне домена. Есть плюсы и минусы, связанные с каждым.

Если я решу использовать уровень Сервиса, я назначу ему роль обработки транзакций и авторизации. Мне нравится держать это "тонким" и не иметь никакой доменной логики там. Это становится API для моего приложения. Я сохраняю всю бизнес-логику с доменными объектами. Это включает в себя алгоритмы и проверки для объекта. Хранилище извлекает и сохраняет доменные объекты. Это может быть взаимно-однозначное соответствие между столбцами базы данных и свойствами домена для простых систем.

Я думаю, что GetAtcitveUsers подходит для репозитория. Вам не нужно извлекать всех пользователей из базы данных и выяснять, какие из них активны в приложении, так как это приведет к снижению производительности. Если ActivateUser имеет бизнес-логику, как вы предлагаете, то эта логика принадлежит объекту домена. За сохранение изменений отвечает слой Repository.

Надеюсь, это поможет.