Вопросы моделирования DDD: студент, класс, места и любимое место для студента - PullRequest
1 голос
/ 26 марта 2010

Я не уверен, как смоделировать эти отношения ...

Классная комната содержит много мест, каждый студент учится в классной комнате и имеет в ней любимое место.

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

А для того, чтобы у студента было фоворитное место, оно должно содержать ссылку на него (место не является совокупным корнем).

Есть предложения? Заранее спасибо, Эрик.

Ответы [ 4 ]

0 голосов
/ 13 сентября 2010

Месяцев после ОП, но на всякий случай это полезно.

@ Джефф Стерн находится на правильном пути. Основная проблема заключается в управлении трехсторонними (тройными) отношениями между студентами, классами и местами. Поскольку это реляционная проблема, давайте пока остановимся на реляционных концепциях и назовем их FavouriteSeat (Student, Classroom, Seat).

Как описано, проблема не требует каких-либо знаний о любом из них, кроме уникального идентификатора. Давайте пока воспользуемся псевдотипом «ID» (на самом деле это не имеет значения, если каждый из них уникален).

В псевдо-sql имеем:

create table FavouriteSeat(
   StudentID ID not null,
   ClassroomID ID not null,
   SeatID ID not null)

Стандартные операции CRUD (создание / чтение / обновление / удаление) для этой таблицы обеспечивают все необходимые операции. Тем не менее, отсутствуют некоторые ограничения. Прямо сейчас у ученика может быть 2 или более любимых места в классе. Хотя это и не указано явно, ОП подразумевает, что у ученика должно быть не более одного (0 или 1) любимого места в любой заданной классной комнате.

Мы можем исправить это, добавив уникальный ключ на стол. Снова используя псевдо-sql:

alter table FavouriteSeat add unique key (StudentID, ClassroomID) 

Теперь у ученика может быть только одно любимое место в любом классе. Там все еще остается вопрос. В настоящее время решение не поддерживает определение того, какие места доступны в каких классах. Мы можем решить это следующим образом:

  1. Добавление новой таблицы со списком действительных мест в каждом классе:

    создать таблицу ClassroomSeat ( Идентификатор ClassroomID не нулевой, Идентификатор SeatID не нулевой)

    изменить таблицу ClassroomSeat добавить уникальный ключ (ClassroomID, SeatID)

  2. Добавление внешнего ключа в таблицу FavouriteSeat, чтобы он мог ссылаться только на действительные ClassroomSeats:

    изменить таблицу FavouriteSeat добавить внешний ключ FK_Seat (ClassroomID, SeatID ссылается на FavouriteSeat (ClassroomID, SeatID).

Вот и все. 2 отношения, 3 ключа и стандартные операции CRUD охватывают все указанные требования.

Реляционная модель может быть легко переведена в OO / DDD. Ему нужны Entity для FavouriteSeat и ClassroomSeat с методами для операций CRUD. Методы должны будут обеспечивать соблюдение ограничений уникального и внешнего ключа, описанных выше.

Чтобы соответствовать только указанным требованиям, Customer, Classroom и Seat могут быть типами значений (хотя могут существовать более широкие неустановленные требования, которые могут изменить это). В любом случае им нужно свойство уникального идентификатора, которое можно проверить в методах FavouriteSeat.

0 голосов
/ 30 марта 2010

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

0 голосов
/ 08 июля 2010

Звучит так, как будто вам нужно ввести объект значения Location, который описывает место в классе, а затем вы можете смоделировать его следующим образом в классе ученика:

public IDictionary<Classroom, Location> FavoriteSeats;

Классные комнаты могут ссылаться на Seat сущностей по их местоположению.

(Если они действительно - это, в первую очередь, сущности - вы даже можете обнаружить, что вам не нужно моделировать сиденья как сущности (например, "синий пластиковый стул, который пахнет гамбургером).)

0 голосов
/ 29 марта 2010

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

...