Код зависим от данных и моделей, а значит от абстракций, используемых в них, поэтому рефакторинг неминуем сегодня. Почему? Обычно под рефакторингом подразумевают реорганизацию кода из соображений необходимости использовать данные по-новому. Мы поговорим о самом частом и нелюбимом типе рефакторинга - лавинообразный рефакторинг, возникающем при изменениях в моделях данных, структурах таблиц и бизнес-логике.
Философия Deep описывает всё концепцией Link. Любой объект это Link, любое отношение это Link. У отношения всегда указаны
fromиto. У самостоятельного объектаfromиtoне указаны. Это также отличает Deep философию от графовых баз данных, там edge не может служить объектом отношений.
Всегда можно попробовать залатать проблемы с обратной совместимостью добавлением новых адаптеров и слоёв. Но эта борьба с симптомами лишь отложит последствия настоящей проблемы. С каждым изменением бизнес-логики эффект луковицы будет только нарастать. И будет становиться больше абстракций, переплетеных друг с другом.
Многие программисты поспорят: “Это вопрос чистоты кода”. Мы не согласны. Чистота кода, это только про его реализацию. Проблема не в том, как мы пишем код, как бы сильно нам не хотелось в это верить. Проблема в том, что он в принципе зависим от абстракций бизнес-логики, и, пытаясь исправить последствия этой проблемы, программисты не уменьшают сложность кода, а лишь умножают её. В то же время программисты окружают себя мнимыми ощущениями комфорта и контроля на ситуацией.
Deep.Case ставит целью победить этого врага. Модели данных могут развиваться, вообще не приводя к рефакторингу. Как? Чтобы объяснить, разберёмся в причинах проблем.
Архитектура может быть разная. Вы можете использовать GraphQL и генераторы схем, или сопоставлять API и абстракции данных через ORM/ODM самостоятельно, пробрасывая правила работы с таблицами кодом. У вас может быть функциональные API и REST API с сервера. Но, вероятно, в любом случае схема работы с этими API будет определена либо на уровне API, либо на уровне имен колонок в таблицах. Таким образом, мы компенсируем вынужденные изменения оплатой разработчиков на то, чтобы обновить базу данных, генераторы, resolver и API. Проблема здесь - разделение реализации функционала и интеграции его в бизнес-логику. Этот слой абстракции множится на пересечения условий бизнес-логики и на обстоятельства связей между колонками, в итоге, делая цену каждой волны, сильно зависимой от возраста проекта. Точно подсчитать фактор зависимости не удалось, но эта цена всегда оказывается кратно больше стоимости самой модификации полей и конечного изменившегося поведения в бизнес-сценарии.
Здесь же приходится учитывать права доступа и любые иные бизнес-правила. Это увеличивает цену таких волн рефакторинга кратно правилам бизнес-логики. Deep.Case позволяет полностью забыть об этой проблеме!
Как бы мы не тешили себя иллюзиями, что можем все предугадать, это, очевидно, не так. Любая, даже самая идеальная модель, будет меняться. То, что мы считали единственной связью, станет множественной. То, что мы считали множественной из одной таблицы, начнет ссылаться из нескольких. Модели, задуманные к применению в одних местах, становятся необходимы во многих прочих. Каждое такое изменение сегодня снова требует участия разработчика.
С Deep.Case данные делятся на:
ЧТО, как например: платеж, объем, потребность, момент, и любые иные.КАК СВЯЗАНО, как например: X хочет Y, W просмотрел Z, T владеет R, T отвечает на P.