2016-07-27 4 views
2

В моем домашнем проекте я столкнулся с проблемой определения типа моего объекта домена.Является ли объект DDD скрытым в моем объекте Value DDD?

домена: Расписание автобусов

Кольцевые контексты: маршрутизации (инфраструктуры общественного транспорта, ctx1), расписание (планирование, ctx2)

Объекты:

  • станция - описывает автовокзал

  • Маршрут (ctx1) - набор станций (Маршрутные путевые точки)

  • Линия (ctx1) - описывает линию шины. Содержит список.

  • Расписание (ctx2) - названный набор отправлений с путевых точек маршрута.

Например: линии шины 25 имеет два маршрута [{ST1, ST3, ST20}, {ST20, ST15, ST3, st1}] и 2 графики (график 1 - маршрут 1, sch2- г2) прикрепленных к этим двум маршрутам.

без сомнений я определил линию и Город как субъекты DDD, агрегатные корни. Кроме того, я решил поместить маршруты в строки, потому что они не имеют смысла за пределами линии и их жизненного цикла == Жизненный цикл Line. Все еще выглядит хорошо.

Следующим шагом является определение объекта домена Расписания. Я хотел отделить его от инфраструктуры общественного транспорта, поэтому я поставил его в другом контексте как сущность. Проблема в том, что теперь мне нужно прикрепить его к маршруту, у которого нет идентификатора.

Мои идеи:

  • график введен в маршрут. Почему это не вариант: Линия становится толстой; создает ubercontext ctx1 и ctx2

  • Сделать маршрут лицом. Почему это не вариант (я думаю ...): хотя нетрудно представить маршрут с каким-то идентификатором (например, Name), вряд ли достаточно представить маршрут шины за пределами линии шины.

Возможно, я сделал что-то совершенно не так?

ответ

3

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

Я также ожидал, что вы захотите задать вопросы маршрута (например, st77 на этом маршруте). Или операции (остановка s99 закрыта на 2 недели). Это означает, что маршрут является сущностью. возможно, ваши стопы являются объектами ценности.

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

Кроме того, идентификатор маршрута не должен иметь значащего имени, он может иметь некоторый случайный указатель в качестве идентификатора. Мой компьютер как серийный номер. Никто никогда не говорит об этом серийном номере (я говорю о dell типа x), но когда я заказал его, это очень хороший номер для идентификации и отслеживания этого конкретного компьютера.

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

+0

Вы сказали: '' 'и строка имеет расписания''' - это то, чего я хочу избежать. Я хочу, чтобы мой домен маршрутизации ничего не знал о домене расписания. Это означает, что объект «Расписание» должен иметь идентификатор маршрута. Но если 'Route' является сущностью в' Line Aggreate Root', я не могу ссылаться на него, пока он является частью Aggreate Root, и единственная возможная ссылка здесь - это связь между 'Schedule' и' Line'. Я прав? – ovnia

+0

это все 1 большой домен (с возможно несколькими корнями совокупности). Но линия, маршрут и график кажутся очень взаимосвязанными. Ваше расписание/расписание зависит от маршрута. Поэтому я не вижу здесь 2 ограниченного контекста – Batavia

+2

+1 Отличное редактирование, Батавия. Достаточно легко понять, как «мы» хотим, чтобы он был смоделирован, но ответ, скорее всего, уже присутствует, если заинтересовать участника. Элементы Вездесущего языка, скорее всего, предсказывают реализацию. Независимо от того, что имеет наибольший смысл с точки зрения развития, это должно быть обусловлено тем, как заинтересованные стороны это видят. Если это не так, это делает общение между командой разработчиков (которая включает в себя экспертов/заинтересованных сторон) сложнее. –

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