Моделирование различных перспектив агрегата в доменно-управляемом дизайне - PullRequest
Новая
       0

Моделирование различных перспектив агрегата в доменно-управляемом дизайне

3 голосов
/ 26 июля 2010

При использовании доменного дизайна я часто сталкиваюсь с проблемой, касающейся различных аспектов доменного объекта, особенно при использовании NHibernate. Перспективы - это, по сути, способы просмотра объекта домена. Например, упрощенная модель: 

class Transaction
{
  string Id { get; set; }
  string CustomerName { get; set; }
  DateTime Date { get; set; }
  decimal Amount { get; set; }
  decimal Tax { get; set; }
}

class Batch
{
    string Account { get; set; }
    string Number { get; set; }
    DateTime? ClearDate { get; set; }
    IList<Transaction> Transactions { get; }
    decimal Total { get; }
}

Общее свойство в пакете - это сумма сумм по каждой транзакции. При рассмотрении одной партии эта модель хорошо работает и является правильным представлением домена. Однако клиентское приложение имеет экран, на котором отображаются коллекции пакетов. Этот экран не требует каких-либо подробностей о транзакциях в пакете, только общая сумма. Использование одного и того же объекта на экране списка медленно. Один из вариантов - сделать свойство Total настраиваемым, другой - создать новый класс, например: 

class BatchOverview
{
    string Number { get; set; }
    decimal Total { get; set; }
}

Это будет иметь свой собственный репозиторий и свое собственное отображение NHibernate на представление базы данных.

  1. Относится ли этот объект к модели предметной области или он более специфичен для конкретного приложения / графического интерфейса?
  2. Должен ли объект обзора партии ссылаться на объект партии?
  3. Это обычная модель?
  4. Есть ли какие-либо рекомендации по этому вопросу?

DDD имеет концепцию ограниченного контекста, однако в этом случае контекст тот же. И класс Batch, и класс BatchOverview ссылаются на один и тот же «фактический» пакет - это разные виды или перспективы на него.

1 Ответ

3 голосов
/ 26 июля 2010

Я бы не пустил новый класс в домен - это проблема презентации в моей книге, и я бы относился к ней как к таковой.Обычно этот новый объект предназначен только для чтения, чтобы не иметь двух способов изменения данных (и один из них не содержит полного набора бизнес-логики).

Однако вам не нужно делатьустановщик для значения только потому, что вы используете nHibernate.Просто сделайте так, чтобы оно использовало вспомогательное поле, и пусть nHibernate записывает это.(используйте access = "field" в вашем отображении).

EDIT: я называю это PresentationModel или ViewModel в зависимости от количества логики внутри.

Я бы, вероятно, сохранил ссылку на оригиналобъект - но может быть только Id.

...