Общий раздел > Методологии
По методологии DDD температура воздуха и метеоэлемент чем является сущностью?
kirka:
Здравствуйте
Температура, да явно не отдельный класс, но почему Метеоэлемент не является отдельным классом?
Мне нужно построить модель которая максимально была бы приближена к будущей БД, не могу понять какие себе вопросы нужно задать чтобы понять разделять или в 1-2 классах все ввести все это.
Основная цель:
- хранить полученные данные
- показать какая сегодня погода
- выделить зоны с опасными явлениями или критическими значениями к примеру, "показать зону где температура превышает 35 градусов и т.д.
- показать прошедшую погоду (редко используемая функция)
Вывел все метеоэлементы (температура, облачность и т.д.) в отдельный классы (1 вариант диаграммы), чтобы избежать лишнего обновления данных всех таблиц.
К примеру: Вчера пришла сводка: Температура 15 градусов, Скорость ветра 10 м/с. Направление ветра 45 градусов.
Сегодня, 06.08.2018, пришли данные только по температуре 25 градусов. В итоге должно отобразится погода так:
Погода на 06.08.2018 Температура 25 градусов
Скорость ветра 10 м/с по состоянию на 05.08.2018
Направление ветра 45 градусов по состоянию на 05.08.2018
Второй вариант, который крутится у меня в голове, это я все значения "положил в один класс" Метеоэлементы. Но здесь смущает, то что все данные храняться в одной таблице. И если нужно будет обновить к примеру только температуру, то как я понимаю всю таблицу нужно будет обновлять...
Третий вариант, разделить прогноз с фактом, но думаю бесмысленно, т.к. метеоэлементы совпадают.
Примечание: классы Единица измерения, и т.д. не отобразил их здесь, потому что с ним у меня проблем, все по ним ясно. А отобразил только проблемные данные, которые вызывают спор.
[прилетело НЛО и...]:
Здравствуйте.
Предыдущее моё сообщение лучше читать в том смысле, что предлагая диаграммы как сырьё для построения ответа на Ваш вопрос, Вы скорее всего получите мало полезные Вам комменты о том, что исходных данных маловато. Затруднительно найти ошибки (или способы улучшения) диаграммы, используя её саму как единственный источник сведений о разрабатываемой модели.
DDD говорит о классе для объектов-сущностей и классе для объектов-значений как о разных типах классов. К Вашим вопросам о том, какие данные в одном классе, какие в другом, сколько и каких классов нужно, это DDD-рассмотрение напрямую не относится. Например, в книжке Эванса "Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем" (вероятно, Вы используете её) на рис. 5.6 Customer -- "сущность", Address -- "значение". Это два разных класса и две (как минимум, в рамках обычных стратегий ORM) разные таблицы.
В связи с этим, хочется ясности, какой вопрос стоит перед Вами? 1) "Построить модель которая максимально была бы приближена к будущей БД" или 2) Разобрать на примере отличия между "сущностями" и "значениями"?
В Вашем ответе появились пояснения. Они немного приподымают занавес над тем, что такое "хранить полученные данные" и "показать какая сегодня погода". Но немного. Для того, чтобы судить о "лишнем обновлении данных всех таблиц" нужен глоссарий ПрО, нужны сценарии. Например, глоссарий (пояснение терминов ПрО и их взаимосвязей) дали бы понять в каком смысле "метеоэлемент" является частью "погоды".
Кажется странным с самого начала озаботиться эффективностью обновлений и схожестью модели классов со схемой будущей БД. Обычно в начале строят простой эскиз, кроющий базовую функциональность, а потом перерабатывают его с учётом вопросов хранения и эффективности.
Дополнительный туман сгущается из-за использования Вами нотации. Ромбики были (и не разрешали двум Погодам иметь общий Метеоэлемент см. "метеоэлементы совпадают"). Теперь ромбиков нету. И надо решать, почему "Метеоэлемент не является отдельным классом" (т. е. в моём прочтении, почему объекты-метеоэлементы у разных погод не могут совпадать).
Вижу, что моё подключение скорее запутывает, а раз так, то спешу улететь.
Кажется, что есть набор "сводок", упорядоченных по дате/времени. У "сводки" есть флажок, является ли она наблюдённым фактом или же прогнозом (замечу, что ожидаемо в прогнозе видеть не точное значение, а диапазон). У "сводки" есть перечень составляющих: t воздуха, t воды, давление, влажность ... . Любой составляющей может не быть. Выводимые сведения о погоде на дату/время дд.мм чч.мм берутся из последней "сводки" из тех, что не позже дд.мм чч.мм, если в ней не все нужные составляющие, то их ищут в предшествующей "сводке" и идут по перечню в сторону против хода времени, пока не соберут все составляющие. Что-то ещё делают со "сводками-прогнозами". Вероятно, когда хотят видеть сведения о погоде, то указывают, что нужно: факт или прогноз.
Такой вот прогноз по увиденному сквозь туман.
kirka:
Да согласен с вами что это туман. Спасибо большое за внимание к вопросу. Я буду думать
[прилетело НЛО и...]:
Гм. Можно зайти с другой стороны. "Сводка" -- это объединение нескольких значений различных параметров погоды, заносимых одновременно. Значение относится к моменту времени и географической точке. Значение либо замеренное, либо прогнозируемое. У значения есть число, единица измерения и параметр погоды, который был замерен или предсказан. Если набор параметров фиксирован, то получается набор классов по 1 на каждый: ТемператураВоздуха, АтмосферноеДавление, Влажность, ... . Если набор не фиксирован, то можно обойтись 1 классом. Вывод "сводки" -- поиск подходящего объекта среди значений нужных параметров погоды.
Навигация
Перейти к полной версии