Уберите модель данных из кода!
Сегодня был на конференции DUMP-2021. В основном присутствовал на секции DevOps, т.к. программа более интересной мне секции Back-end была на удивление слабой. На два доклада по Back-end, однако, я зашел - и был поражен вещам, которыми люди не только занимаются до сих пор, но и считают возможным об этом публично рассказывать.
Один доклад был посвящен "чистой архитектуре" - паттерну проектирования, который "углубляет и расширяет" самые кондовые идеи ООП и MVC, намертво зашивая в код структуру данных и бизнес-логику. Люди используют это в энтерпрайзе. Единственное объяснение, которое я могу найти этим практикам как минимум 30-летней идейной давности, состоит в том, чтобы брать с заказчика побольше денег за постоянную доработку кода, которая необходима при любом изменении в "автоматизируемых" такими средствами процессах.
Другой доклад был посвящен переносу одного известного публичного сервиса на GraphQL. Докладчики начали с похвального тезиса о том, что на каком-то этапе развития сервиса они столкнулись с необходимостью описать его модель данных, чтобы разные компоненты могли общаться между собой в ее терминах. В качестве решения они выбрали GraphQL, что само по себе неплохо. Но основное содержание доклада совсем не впечатлило: время, затраченное на разработку, не коррелирует со скромностью достигнутых результатов, а проблемы, которые решали докладчики, были, скажем так, простоваты.
Предлагаю всем разработчикам, которые на каком-то этапе развития своих продуктов приходят к мысли о необходимости машинно-читаемого представления модели данных, на такой мысли не останавливаться, а спроектировать сразу:
Что вы получите в результате? Огромную гибкость, возможность масштабировать решение при росте объема данных и сложности их структуры, реализацию новых фич за дни, а не месяцы.
Чем за это придется заплатить? Только небольшим напряжением ума и выходом за пределы накатанной колеи.
Один доклад был посвящен "чистой архитектуре" - паттерну проектирования, который "углубляет и расширяет" самые кондовые идеи ООП и MVC, намертво зашивая в код структуру данных и бизнес-логику. Люди используют это в энтерпрайзе. Единственное объяснение, которое я могу найти этим практикам как минимум 30-летней идейной давности, состоит в том, чтобы брать с заказчика побольше денег за постоянную доработку кода, которая необходима при любом изменении в "автоматизируемых" такими средствами процессах.
Другой доклад был посвящен переносу одного известного публичного сервиса на GraphQL. Докладчики начали с похвального тезиса о том, что на каком-то этапе развития сервиса они столкнулись с необходимостью описать его модель данных, чтобы разные компоненты могли общаться между собой в ее терминах. В качестве решения они выбрали GraphQL, что само по себе неплохо. Но основное содержание доклада совсем не впечатлило: время, затраченное на разработку, не коррелирует со скромностью достигнутых результатов, а проблемы, которые решали докладчики, были, скажем так, простоваты.
Предлагаю всем разработчикам, которые на каком-то этапе развития своих продуктов приходят к мысли о необходимости машинно-читаемого представления модели данных, на такой мысли не останавливаться, а спроектировать сразу:
- Универсальный API для работы с данными, соответствующими модели. Бэк-энд, реализующий такой API, должен быть способен хранить данные в различных СУБД с разными моделями хранения, и должен быть совершенно абстрагирован от конкретного содержания данных. Если дойти в этом до логического конца, то ваш бэк вообще не будет связан с моделью данных - и это прекрасно!
- Формализм для описания правил обработки объектов данных и механизм исполнения таких правил. Это позволит вынести из кода не только жесткую привязку к структуре данных, но и какую-то часть логики их обработки.
Что вы получите в результате? Огромную гибкость, возможность масштабировать решение при росте объема данных и сложности их структуры, реализацию новых фич за дни, а не месяцы.
Чем за это придется заплатить? Только небольшим напряжением ума и выходом за пределы накатанной колеи.