Общий раздел > Методологии

По методологии DDD температура воздуха и метеоэлемент чем является сущностью?

(1/2) > >>

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

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

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

с уважением

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

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

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

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

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

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

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

Galogen:

--- Цитата: kirka от 29 Июля 2018, 21:35:31 ---Спасибо за оперативный коментарий.

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

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

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


--- Конец цитаты ---

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

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

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

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

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

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

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

Навигация

[0] Главная страница сообщений

[#] Следующая страница