Здравствуйте

Сделал диаграмму предметной области. Теперь нужно диаграмму привести в соответствии с методологией DDD (Domain Driven Design).
По методологии DDD: сущности, Объект-Значение, Служба Предметной Области, Агрегат, Репозиторий и т.д.
Прочитал, но не совсем понял.

Подскажите пожалуйста, что в моей диаграмме является сущность, а что объектом значения? И почему?
Правильно ли моя диаграмма сделана с точки зрения DDD?

с уважением

К сожалению с DDD-методологией знаком лишь в общих чертах. По какому источнику вы готовитесь, изучаете методологию DDD?

Но я посмотрел на вашу диаграмму, и она вызывает у меня массу вопросов.
Почему вы используете практически везде композицию?
Погода является композитом метеоэлементов и прогнозов?
Метеоэлемент - композит температуры, облачности и ветра?
А Облачность - композит формы облачности?

А разве факт - это погода?

Спасибо за оперативный коментарий.

Чуть ошибься. Факт и прогноз наследует Погоду.

Погода бывает фактической, либо прогнозной.
Метеоэлемент является частью погоды
Температура является частью Метеоэлемента

Примеры:
09.10.2017 наблюдается Температура 35 градусов, форма облаков грозовые
10.10.2017 наблюдается Температура 35 градусов
Прогноз на 11.10.2017 Температура 45, Средняя скорость ветра 10

Спасибо за оперативный коментарий.

Чуть ошибься. Факт и прогноз наследует Погоду.

Погода бывает фактической, либо прогнозной.
Метеоэлемент является частью погоды
Температура является частью Метеоэлемента

Примеры:
09.10.2017 наблюдается Температура 35 градусов, форма облаков грозовые
10.10.2017 наблюдается Температура 35 градусов
Прогноз на 11.10.2017 Температура 45, Средняя скорость ветра 10

Поскольку это модель предназначенная не для индивидуального потребления, то все-таки нужно давать именования классам так, чтобы они отражали суть онтологии предметной области, следовательно не факт или прогноз, а
так и давать Погода по факту, Прогноз погоды - а общий класс Погода (абстрактный)

Однако вопрос, а зачем вам иерархия наследования в этом случае? чем по составу атрибутов будет отличаться один класс от другого. Почему выбрана именно иерархия? А например не один класс Погода с флагом : Факт/прогноз?

Метеоэлемент - зачем для температуры нужно выделять класс? Это же просто свойство метеоэлемента? насколько обосновано выделать класс Температура, который идентифицируется исключительно через свою связь с элементом и содержите единственный атрибут - значение этой самой температуры?

Я к тому, а почему бы просто не иметь единственный класс
Погода с атрибутами - Дата, Температура, Облачность, Ветер и т.п.

Предлагая вопрос, Вы также предлагаете по ключевым словам "погода", "прогноз" догадаться, что именно Вы моделируете. Это может быть трудно или невозможно. Но от точности догадки зависит ответ на Ваш вопрос, если анализировать по смыслу.

Формально, если верить Вашим композициям (анализ по смыслу я не провожу), то Температура не может быть сущностью, т. к. не расшаривается. Аналогично, Метеоэлемент. Поясню. Если в разных экземплярах Метеоэлемента одна и та же температура "Fahrenheit 451", то в Вашей модели это должны быть два разных экземпляра Температуры, равенство которых Вы установите не по тому, что соединения от обоих экземпляров Метеоэлемента идут в одно и то же место. Если бы на диаграмме была надпись {readOnly} перед атрибутом Температуры, это бы ещё больше  убеждало, что перед нами объект-значение.

Как непрошенный совет получите рекомендацию сначала перетрясти набор классов и набор их атрибутов, а уж потом переходить к DDD-анализу. Так, температура (как и, например, длина) может измеряться в разных "градусах" (в примере с длиной -- в "попугаях", в "слонёнках", в "мартышках").

Здравствуйте

Температура, да явно не отдельный класс, но почему Метеоэлемент не является отдельным классом?

Мне нужно построить модель которая максимально была бы приближена к будущей БД, не могу понять какие себе вопросы нужно задать чтобы понять разделять или в 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 воды, давление, влажность ... . Любой составляющей может не быть. Выводимые сведения о погоде  на дату/время дд.мм чч.мм берутся из последней "сводки" из тех, что не позже дд.мм чч.мм, если в ней не все нужные составляющие, то их ищут в предшествующей "сводке" и идут по перечню в сторону против хода времени, пока не соберут все составляющие. Что-то ещё делают со "сводками-прогнозами". Вероятно, когда хотят видеть сведения о погоде, то указывают, что нужно: факт или прогноз.

Такой вот прогноз по увиденному сквозь туман.

Да согласен с вами что это туман. Спасибо большое за внимание к вопросу. Я буду думать

Гм. Можно зайти с другой стороны. "Сводка" -- это объединение нескольких значений различных параметров погоды, заносимых одновременно. Значение относится к моменту времени и географической точке. Значение либо замеренное, либо прогнозируемое. У значения есть число, единица измерения и параметр погоды, который был замерен или предсказан. Если набор параметров фиксирован, то получается набор классов по 1 на каждый: ТемператураВоздуха, АтмосферноеДавление, Влажность, ... . Если набор не фиксирован, то можно обойтись 1 классом. Вывод "сводки" -- поиск подходящего объекта среди значений нужных параметров погоды.