Доброго времени суток. Хотел бы получить консультацию от более опытных коллег в плане построения архитектуры по следующему вопросу:
В системе есть разные объекты, с которыми взаимодействуют пользователи. Для примера, статьи в блоге и тикеты для администратора. 2 этих объекта никак не связаны, с точки зрения кода находятся в разных модулях и у них нет никаких зависимостей друг от друга. Но у каждого из них есть статус (обычное поле в БД). Эти статусы должны меняться, причем разные роли в системе могут видеть эти объекты только в определенных статусах. Пользователи могут менять эти статусы, если такая возможность есть.
Для перехода по статусам есть отдельные таблицы в БД. Общая структура такая: есть некие воркфлоу, которые закрепляются за тем или иным типом объектов (свой воркфлоу для поcтов, свой для тикетов). Есть таблица с транзакциями, в ней указывается, из какого статуса в какой может быть переведен объект. И есть таблица ограничений, в которой указывается, какой роли в каком статусе может быть доступен объект.
Задача сводится к тому, что нужно организовать отдельный модуль, который будет управлять статусами разных объектов, сразу вопрос, правильно ли это? Если правильно, то еще вопрос: при переходе определенного объекта в определенный статус, может срабатывать какое либо событие. Эту задачу планировалось решить, навешиванием события на транзакцию (то есть когда происходит переход с одного статуса в другой), но тоже не уверен, правильно ли это.
Может у кого-то есть опыт написания подобного, или знаете хорошие практики для таких вещей, буду благодарен, если поделитесь. Потому как у меня есть сомнения в правильности такого универсального подхода. Подобная штука реализована в JIRA, но там отличие в том, что есть только один объект в системе - задачи, а тут их может быть бесконечно много.
Пример не очень хороший. Тут очень сильно зависит от предметной области. Если вы разрабатываете систему управления всякими вокрфловами, в которых могут участвовать разные сущности, то наверное да, однако тут можно зайти с другой стороны - что если выделить класс сущностей, которые могут использоваться в управлении воркфлоу как отдельную сущность, которая может нести разную полезную нагрузку в зависимости от типа? Тогда статус будет атрибутом этой сущности, а полезная нагрузка уже будет выносится в компоненты той же самой Стратегии...
Если же, как в примере, вы просто заметили схожесть процессов работы с разными сущностями, то скорее всего не стоит париться. Можно конечно унифицировать, но когда сущности действительно разные, рано или поздно появятся различия, ради поддержки которых придётся хакать свою же систему.
У меня на работе мы создали унифицированную систему (и да, там ключевую роль играют статусы) по работе с разного рода заявками/тикетами/уведомлениями, но этому предшествовало пара лет работы с этим же функционалом, реализованным отдельно.
что если выделить класс сущностей, которые могут использоваться в управлении воркфлоу как отдельную сущность, которая может нести разную полезную нагрузку в зависимости от типа?
Вы тут имеете в виду, выделить один класс, который по типу, который он получает на входе, будет делегировать управление другим сервисам?
Средний
