Форум Сообщества Аналитиков
Дисциплины => Проектирование => Тема начата: Aliga от 02 Марта 2016, 14:41:56
-
Добрый день!
Вопрос связан с подходом в разработке некоторой системы, когда жизненный цикл некой сущности "A", разрешает на определенном этапе опционально регистрировать другую сущность "Б". Причем эта новая сущность "Б" имеет собственный жизненный цикл, который имеет влияние на жизненный цикл сущности "A" (запрещает переход к некоторым состояниям). Завершить жизненный цикл сущности "А" можно лишь тогда, когда или нет сущности "Б", или жизненный цикл сущности "Б" завершён.
В итоге возникает ключевой вопрос каким образом следует контролировать согласованность этих сущностей, как минимум рассматривается 2 варианта:
- 1 вариант. Синхронизация жизненных циклов сущностей "А" и "Б" с помощью предикатов (переход между состояниями возможен, если выполняется условие)
- 2 вариант. Объединение жизненных циклов сущностей и самих сущностей "A" и "Б" в одну сущность "B" с одним жизненным циклом
Сталкивались ли вы с такой проблемой и как бы вы обеспечивали согласованность жизненных циклов сущностей?
-
А в чем выгода от объединения и сложность синхронизации?
IMHO если рассматривать варианты абстрактно, то они равнозначны. Отличия проявляются при реализации и определяются контекстом разработки
-
Выгода от объединения связана с упрощением разработки и обеспечением синхронизации состояний сущностей при отмене последнего перехода и возврату к предыдущему состоянию.
С другой стороны в проекте разработка ведется по методологии Domain Driven Design откуда следует, что реализация не должна сильно расходиться с моделью. Поэтому для проекта существенен выбор варианта модели
-
Сталкивались ли вы с такой проблемой?
Часто.
и как бы вы обеспечивали согласованность жизненных циклов сущностей?
Обеспечивали по первому варианту. Поскольку практически всегда по отпочкованным сущностям нужен свой учет, а организовать под это дело вычленялку Б из В непросто (когда вообще возможно) и недешево с точки зрения вычислительных мощностей.
Не исключаю ситуаций, в которых более интересным окажется вариант 2. Однако это бомба под дальнейшее развитие.
-
Объединение сущностей, как правило, чревато появлением избыточности и денормализацией. Труднее определять связи третьих сущностей по отношению к обьединенным
То как вы описываете синхронизацию, похоже на то, что понадобится пара триггеров. Я б на вашем месте пообщался с разработчиками. Если их инструментарий ориентирован на работу с жц, то там обязательно при описании переходов задаются условия перехода.
Так что может вы преувеличиваете сложность реализации варианта с синхронизацией, а при этом ухудшаете свойства модели.
С другой стороны, если сущности близкие и эффекты денормализации минимальные, то почему бы нет
-
Сталкивались ли вы с такой проблемой и как бы вы обеспечивали согласованность жизненных циклов сущностей?
Сталкивался не раз.
Из свежего: в системе управления требованиями регистрируются (сюрприз!) сущности типа "требование". В этой же системе с каждым требованием может быть связан один или несколько вариантов решения (вторая сущность). На определённом этапе одно из решений должно быть выбрано, и дальше требование рассматривается с выбранным решением как единое целое.
Это был ответ на первую половину вопроса.
А вторую половину нужно уточнить: что значит "обспечить согласованность"? На каком уровне? На уровне понимания, описательной модели, модели реализации, структуры БД?
-
Коллеги, спасибо за ваши комментарии. В заключении могу сказать, что определяя скрытые риски, вы помогли корректно выбрать решение.
-
В этой же системе с каждым требованием может быть связан один или несколько вариантов решения (вторая сущность). На определённом этапе одно из решений должно быть выбрано, и дальше требование рассматривается с выбранным решением как единое целое.
Я бы выбранное решение описал как отдельную сущность, связанную с требованием и решением.
Унарные связи - зло. Как правило это заплатка
-
Я бы выбранное решение описал как отдельную сущность, связанную с требованием и решением.
Унарные связи - зло. Как правило это заплатка
Это если есть возможность создавать свою структуру БД. В нашем случае нужно эти сущности реализовывать на базе архитектуры имеющейся системы управления задачами, довольно жёсткой.
-
Это если есть возможность создавать свою структуру БД. В нашем случае нужно эти сущности реализовывать на базе архитектуры имеющейся системы управления задачами, довольно жёсткой.
Вот о том и речь . 1:1 как правило в результате допиливаний и появляются