Перспективы организации
Контекст: Итак, я пытаюсь построить до смешного сложную модель предметной области. Говоря с пользователями, есть несколько способов использования системы (например: один способ - с точки зрения сотрудника; другой - с точки зрения работодателя). На самом деле это несколько приложений, повторно использующих основной домен.
Вопрос: Неправильно ли создавать домен с нескольких точек зрения? Например, создание домена по мере ведения бизнеса означало бы создание всех видов классов отношений, которые несут дополнительную информацию об объекте и так далее ... Однако при работе с определенной точки зрения картина становится намного яснее, потому что большая часть классы отношений могут быть объединены в их родительскую сущность.
Идеи? Опровержения? Я совсем не на базе?
Ответы 2
Я не думаю, что вам следует заранее определять «основной домен». Пусть это проявляется в процессе разработки. Кроме того, все, что не является общим для двух (или более) перспектив, не должно быть в «ядре».
Например, постройте часть системы с точки зрения сотрудника. Это может побудить вас создать такие объекты, как «Проект», «Задача» и «Клиент». Затем создайте часть с точки зрения работодателя. Это может побудить вас создать новые объекты и повторно использовать «Проект» и «Задача». Именно тогда я переместил «Проект» и «Задачу» в «базовую библиотеку», разделяемую остальной частью системы.
Иногда можно встретить общие сущности, но связанные по-разному. В этом случае связь должна быть введена контекстом, а не встроена в сами сущности.
Нет, это абсолютно уместно. Эван называет эти «перспективы» ограниченными контекстами в своей книге.
Вместо того, чтобы иметь действительно сложную модель предметной области, попробуйте построить простую, которая действительно хорошо обращается к предметной области определенным образом. Ограниченные контексты можно связать вместе, чтобы сформировать сеть меньших, более простых, прямых моделей предметной области.
У меня есть книга Эрика, и я, видимо, забыл об этой главе. Спасибо за направление.