2013-03-31 4 views
2

Я просто пытаюсь выйти из своей комфортной зоны типичной архитектуры хранилища/службы/презентации N-Tier и начал изучать DDD с помощью агрегатов, и я должен признать, что я «м немного смущены и надеялся, что кто-то может прояснить следующий пример:Как моделировать агрегаты и сохраняться в базе данных в DDD

Если бы я имел Entity под названием News, NewsImage и клиентов, которые были все EF сохраняются, способные объекты, как так:

public class Customer 
{ 
    public virtual int Id { get; set; } 
    public virtual string Name { get; set; } 
} 

public class NewsImage 
{ 
    public virtual int Id { get; set; } 
    public virtual byte[] Data { get; set; } 
    public virtual News News { get; set; } 
} 

public class News 
{ 
    public virtual int Id { get; set; } 
    public virtual string Name { get; set; } 
    public virtual ICollection<NewsImage> NewsImages { get; set; } 
    public virtual Customer Customer { get; set; } 
} 

в I понять, что это могут быть объекты, которые мы будем использовать для сохранения объектов домена в базе данных, но если мы используем агрегаты из домена mod эш мы могли бы иметь что-то вроде этого:

public class NewsAggregate 
{ 
    public int Id { get; set; } 
    public string Name { get; set } 

    public void AddImageToNews(byte[] imageData) 
    { 
     // Hide NewsImage or that object and add the byte[] data here? 
    } 
} 

Моих вопросов следующие, и я был бы признателен за любые разъяснения, как я уверен, я недопонимание основных принципов здесь:

  1. только агрегированные объекты должны подвергаться к слою презентации (или к любому поглощающему слою).
  2. Как обрабатывать преобразование/сохранение агрегированных объектов в базу данных, я мог бы использовать сопоставление, которое прекрасно, но затем, как я узнаю, создаю ли я объект или обновление (по тому, является ли оно временным, если идентификатор установлен или не?). Как узнать, были ли добавлены новые изображения и какие обновления или удаления? Я думаю, что проблема, с которой я столкнулась, - это вызов, чтобы передать агрегат новостей в репозиторий и создать его, я мог бы вернуть агрегат обратно из домена, заполненного через объекты EF, а затем добавить изображение, когда я передаю агрегат новостей назад, как я могу узнать, что изменилось для создания/обновления данных?
    1. Куда должен идти клиент, должен ли он быть на агрегированном объекте новостей в качестве метода AddCustomer, должен ли быть элемент CustomerAggregate, который имеет метод AddNews, и с обеими этими параметрами, как упорствовать?

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

ответ

1

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

DDD - это методология, предназначенная для решения сложных бизнес-правил. Вы не должны использовать его, если ваше значение приложения находится в технологическом активе (находясь в облаке, подвергая веб-сервисы или какой-то хороший html5/мобильный интерфейс), но в сложности бизнеса, который он обрабатывает.
Вы не должны использовать DDD для простых бизнес-правил. Эмпирическое правило: если вам не нужен эксперт домена для понимания бизнеса, вам вообще не нужен DDD.

Затем, чтобы правильно понять агрегаты, вы должны прочитать Vernon's essay on the topic. Это эссе объясняет, что агрегаты существуют для обеспечения бизнес-инвариантов. Вы не должны использовать агрегаты только для оптимизации доступа к db.

2

1) Это зависит от того, какую емкость. Существует правило, согласно которому агрегаты могут ссылаться только на другие агрегаты напрямую, а не на объекты или объекты значений, содержащиеся в других агрегатах.Это необходимо для обеспечения агрегатов как границ согласованности - они полностью инкапсулируют то, что они «агрегируют». Должен быть репозиторий на совокупность. Уровень представления и любой внешний слой могут потребовать ссылки на агрегаты в двух общих емкостях - для показа или для поведенческих целей. Агрегат не должен слишком сильно зависеть от того, как он будет отображаться, потому что запросы могут быть реализованы с использованием другой модели, более подходящей для задачи - read-model. Вместо этого агрегат должен сосредоточиться на поведении. И да, в тех случаях, когда слой представления хочет выполнить поведение в совокупности, он должен ссылаться на совокупность по своей идентичности. Еще лучше, создайте application service, чтобы инкапсулировать слой домена и выставить поведение как простой фасад.

Кроме того, совокупность не является одним классом, но обычно представляет собой набор классов, кластерных вокруг совокупного корня, который является сущностью. Для представления совокупности необязательно нужен отдельный класс, это может быть только корневой объект.

2) Для настойчивости кажется, что вы используете EF, который должен обрабатывать все отслеживания изменений для вас. Он должен следить за тем, какие объекты являются постоянными или временными. ORM, такие как NHibernate, также делают это.

2.1) Это зависит от того, является ли Customer сам по себе агрегатом. Если это так, то News должен указывать только Customer. Более того, может быть, что клиент нужен для новостного объекта, и в этом случае идентификатор клиента должен быть передан конструктору объекта новостей. Если это не требуется, то возникает поведение, связанное с клиентом с объектом новостей. Рассмотрите это с точки зрения домена - в чем смысл ассоциирования клиента с объектом новостей? Попытайтесь отойти от мышления в техническом, CRUD-способе, таком как AddCustomer, и подумайте больше о целях бизнеса.

Как указано Giacomo Tesio, DDD показывает свое значение в доменах с некоторой сложностью в бизнес-логике. Если все ваши поведения могут быть сопоставлены с CRUD, то оставьте его CRUD. В противном случае, посмотрите на поведение в своем домене, вместо того чтобы сосредоточиться на данных. Ваши объекты и объекты значений должны раскрывать поведение и скрывать состояние как можно больше. Прочитайте и перечитайте ссылочную статью: Effetive Aggregate Design by Vaughn Vernon.

Смежные вопросы