Комментарии 4
А монолит надо всегда на "микро" сервисы пилить? Компромиссы тут не уместны?
Давайте по порядку. Сам паттерн Strangler вполне применим при рефакторинге и монолита и вообще любого приложения. Это даже и на картинках у меня показано. Во-вторых. Я не считаю, что монолит всегда должен быть распилен на микросервисы. Это лишь один из способов. У него есть плюсы и минусы. Из минусов, например, высокие требования к развитию инфраструктуры... Но это тема для отдельной статьи. Тут, конечно, нужно упомянуть Kamil Grzybek и его Modular Monolith. Думаю загуглите, если не видели еще.
Чтобы не было необходимости в последующем рефакторинге, нужно строить модель данных независимо от того, как они в настоящее время используются (возможно, они используются неэффективно). Т.е. в процессе разработки полностью исключить такую хрень, как сценарии взаимодействия участников (юзеркейсы) — все это само нарисуется в виде возможностей, которые позволяет предоставить модель данных после ее разработки. Причем этих самых сценариев будет на порядок больше и все они будут непротиворечивыми и разумными. Останется всего лишь flow chart редактор для этих сценариев написать и статические формы для поддержки этих flow charts.
Есть правило — базы данных должны полно отражать предметную область и не должны зависеть от того, как и кто ее будет использовать — сценарии использования вторичны и определяются структурой данных, над которой они выстраиваются. Будут ли когда-нибудь в реальных сценариях взаимодействия с базой использоваться те или иные отношения и связи, в ней содержащиеся, не должно влиять на их наличие — они должны быть построены и обслуживаться безусловно.
Модели, структуры данных и операции над ними в области управления складами, магазинами и прочими продажами, которые обеспечивают достаточную для всех масштабируемость, надежность и приемлемую производительность, а также максимальную функциональную гибкость, давно разработаны, исследованы, вылизаны теоретиками. Все это апробировано в виде рабочего кода в начале 70-х, еще до того, как появился язык SQL, поэтому остается просто тупо реализовывать эти модели и операции не рефлексируя, поскольку с тех пор ничего нового в управлении данными не появилось. Под под капотом того же декларативного SQL лежит старый добрый ISAM, в терминах которого сегодня описываются все реляционные и не очень модели данных.
Есть правило — базы данных должны полно отражать предметную область и не должны зависеть от того, как и кто ее будет использовать — сценарии использования вторичны и определяются структурой данных, над которой они выстраиваются. Будут ли когда-нибудь в реальных сценариях взаимодействия с базой использоваться те или иные отношения и связи, в ней содержащиеся, не должно влиять на их наличие — они должны быть построены и обслуживаться безусловно.
Модели, структуры данных и операции над ними в области управления складами, магазинами и прочими продажами, которые обеспечивают достаточную для всех масштабируемость, надежность и приемлемую производительность, а также максимальную функциональную гибкость, давно разработаны, исследованы, вылизаны теоретиками. Все это апробировано в виде рабочего кода в начале 70-х, еще до того, как появился язык SQL, поэтому остается просто тупо реализовывать эти модели и операции не рефлексируя, поскольку с тех пор ничего нового в управлении данными не появилось. Под под капотом того же декларативного SQL лежит старый добрый ISAM, в терминах которого сегодня описываются все реляционные и не очень модели данных.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чему можно научиться у фикуса-душителя? Паттерн Strangler