Сергей Горшков (serge_gorshkov) wrote,
Сергей Горшков
serge_gorshkov

Category:

Уберите модель данных из кода!

Сегодня был на конференции DUMP-2021. В основном присутствовал на секции DevOps, т.к. программа более интересной мне секции Back-end была на удивление слабой. На два доклада по Back-end, однако, я зашел - и был поражен вещам, которыми люди не только занимаются до сих пор, но и считают возможным об этом публично рассказывать.

Один доклад был посвящен "чистой архитектуре" - паттерну проектирования, который "углубляет и расширяет" самые кондовые идеи ООП и MVC, намертво зашивая в код структуру данных и бизнес-логику. Люди используют это в энтерпрайзе. Единственное объяснение, которое я могу найти этим практикам как минимум 30-летней идейной давности, состоит в том, чтобы брать с заказчика побольше денег за постоянную доработку кода, которая необходима при любом изменении в "автоматизируемых" такими средствами процессах.

Другой доклад был посвящен переносу одного известного публичного сервиса на GraphQL. Докладчики начали с похвального тезиса о том, что на каком-то этапе развития сервиса они столкнулись с необходимостью описать его модель данных, чтобы разные компоненты могли общаться между собой в ее терминах. В качестве решения они выбрали GraphQL, что само по себе неплохо. Но основное содержание доклада совсем не впечатлило: время, затраченное на разработку, не коррелирует со скромностью достигнутых результатов, а проблемы, которые решали докладчики, были, скажем так, простоваты.

Предлагаю всем разработчикам, которые на каком-то этапе развития своих продуктов приходят к мысли о необходимости машинно-читаемого представления модели данных, на такой мысли не останавливаться, а спроектировать сразу:

  • Универсальный API для работы с данными, соответствующими модели. Бэк-энд, реализующий такой API, должен быть способен хранить данные в различных СУБД с разными моделями хранения, и должен быть совершенно абстрагирован от конкретного содержания данных. Если дойти в этом до логического конца, то ваш бэк вообще не будет связан с моделью данных - и это прекрасно!

  • Формализм для описания правил обработки объектов данных и механизм исполнения таких правил. Это позволит вынести из кода не только жесткую привязку к структуре данных, но и какую-то часть логики их обработки.

Стек OWL/SHACL предоставляет готовые спецификации для таких вещей, которые с небольшим усилием легко сопрячь с тем же GraphQL (смотрите в документации, как мы это сделали). Наша платформа дает весь описанный функционал "из коробки", и готова служить бэк-эндом для практически любых сервисов обработки данных; у нас есть опыт сотрудничества со сторонними разработчиками, которые используют такой подход. Но, конечно, описанный мной архитектурный паттерн можно реализовать и другими средствами.

Что вы получите в результате? Огромную гибкость, возможность масштабировать решение при росте объема данных и сложности их структуры, реализацию новых фич за дни, а не месяцы.
Чем за это придется заплатить? Только небольшим напряжением ума и выходом за пределы накатанной колеи.
Tags: автоматизация, программирование, семантические технологии
Subscribe

Recent Posts from This Journal

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 3 comments