DDD и получение дополнительной информации в классе домена

Question

Я думаю, что прочитал 16 154 вопроса, сообщения в блогах, твиты и т. Д. О DDD и лучших практиках. Извинения за еще один вопрос такого типа. Предположим, у меня три таблицы в моей базе данных, User, Department и UserDepartment. Все очень просто. Мне нужно создать иерархию, показывающую, к каким отделам имеет доступ пользователь. Проблема в том, что мне также необходимо показать родительские отделы тех, к которым у них есть доступ.

Лучше ли иметь метод GetDepartments() в моем классе пользователей? Сейчас у меня есть пользовательский сервис с GetDepartments (string userName), но я не чувствую, что это оптимальное решение. Если user.GetDepartments() предпочтительнее, то как мне получить доступ к репозиторию, чтобы получить родительские отделы для тех, к которым пользователь имеет доступ?

Не думайте, что это имеет значение, но я использую Entity Framework.

public class User 
{ 
    [Key] 
    public int UserId { get; private set; } 

    [Display(Name = "User Name")] 
    public string UserName { get; private set; } 

    [Display(Name = "Email")] 
    public string Email { get; private set; } 

    [Display(Name = "UserDepartments")] 
    public virtual ICollection<UserDepartment> UserDepartments { get; private set; } 

    public List<Department> GetDepartments() 
    { 
     // Should this be here? and if so, what's the preferred method for accessing the repository? 
    } 
} 

Answer 1

DDD больше о поведении, что также означает, что она является TDA (говорят, не спрашивайте), ориентированных.

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

Более того, если какая-либо дополнительная информация требуется для агрегата, чтобы выполнить его поведение, обычно не их задача выяснить, откуда получить эту информацию.

Теперь, когда вы говорите, что ваш агрегат пользователя имеет метод GetDepartments, он вызывает звонок. Нужен ли агрегат этой информации для выполнения какого-либо поведения? Я так не думаю, вам просто нужно отобразить некоторые данные.

Так что я вижу здесь, что вы пытаетесь структурировать свои агрегаты против таблиц данных, а не по поведению . Это фактически # 2 ошибка при применении DDD (# 1 не думает о ограниченных контекстах).

Снова, агрегаты представляют business logic и поведение вашей системы. Это означает, что вам не нужно читать из агрегатов. Ваша сторона чтения может быть сделана намного проще - просто сделайте проклятый запрос к БД.

Но как только вы должны спросить свою систему на do что-то - теперь вы делаете это через агрегаты: AppService загрузит один из репозитория и вызовет его метод поведения.

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

Кроме того, вы не хотите, чтобы ваши агрегаты отображались в таблицах данных в любом случае, это не их работа, а работа репозиториев. Фактически, вы не хотите, чтобы ваш домен зависел от чего-либо, особенно от инфраструктуры.

Так что если вы хотите идти на направлении DDD, то рассмотрим следующие:

1. Структура ваши агрегаты инкапсулировать поведения, не представляют таблицы данных
2. Не заставляйте вашего домена зависит от инфраструктуры, и т. д.
3. Сделать хранилища ответственными за загрузку/сохранение агрегатов. Агрегаты сами не должны знать ничего о сохранении, структуре данных и т. Д.
4. Вам не нужно читать данные через агрегаты.

Думайте о # 4, так как ваша система имеет две стороны: «прочитанную», когда вы просто читаете данные и показываете их в пользовательском интерфейсе, а «команда» - при выполнении действий.

Первый (прочитанный) очень прост: глупые запросы для чтения данных так, как вы этого хотите. Это ничего не влияет, потому что это просто чтение, никаких побочных эффектов здесь.

Второй, когда вы вносите изменения и , что проходит через ваш домен.

Опять же, помните первое правило DDD: если у вас нет бизнес-логики и поведения для модели, не делайте DDD.