Сразу извиняюсь за свою манеру повествования, ибо она похоже больше на поток сознания, но главное уловить суть, которую я хочу донести.
Я хочу подготовить небольшой цикл публикаций про работу с данными:
Общий обзор FOR-архитектуры (эта статья)
Взгляд на валидацию данных и частные применения
Разбор FOR со стороны поставщика данных (ключевая часть, нужная для понимания всей картины)
Гомогенность данных в больших распределенных системах (идея, выросшая из валидации и использующая те же механизмы)
Начнем с определения кому надо
Если рассматривать разработку веб приложений, то я бы выделил 2 вектора:
Первый - будем называть студийная, когда глубина проработки ниже и обусловлена срочностью бизнеса, ему "надо продавать сегодня".
Второй - enterprise, это когда есть 1 продукт (или больше, что не важно в данном контексте) и он должен быть сделан на уровне, когда поддержка должна быть простой и легкой десятилетиями.
Если мы рассматриваем студийный подход - то имеем более низкую вовлеченность в предметную область (domain driven) и подходы ограничены более простым и менее проработанным ТЗ (как правило, судя по моему опыту, не пытаюсь сказать, что в студиях пишут хуже, просто там как правила оплата не по часам, а по проектно, а с большими студиями я не сталкивался) а вот в энтерпрайзе уже надо сделать более качественно, потому что нам (писателям кода) и надо будет поддерживать и расширять код под постоянно изменчивый бизнес (и лишь такой бизнес хорошо живет, а не тот, кто может позволить быть в статике).
Данный параграф обозначил аудиторию моего подхода и моих идей, я полагаю не стоит в "быстрой" разработке использовать то, что я предлагаю, потому что это будет сильно дольше и, соответственно, дороже.
Начнем с ситуации. Рассмотрим 2 кейса.
Первый:
У вас react/vue/что-то иное
Есть некий компонент (форма создания какой-то элемента)
Поля формы сильно отличаются от контекста и типа этого элемента (к примеру, товары в магазине)
Программист в начале имел всего 3 типа и всё было хорошо. Он за каждым ходит на бек, прямо внутри всего чудного компонента
Где-то в дебрях:
let form_data = axios.get(element_type);
По моему видению, это всегда должно быть иначе
let form_data = FormProvider.get_by_type(element_type);
Плюсы очевидны по мне.
Низкая связанность
Не зависимость от поставщика
Легкий рефакторинг (данных)
Мы можем добавить ttl-кеш в наш провайдер (логи, единая точка валидации отправляемых и получаемых данных по роута и многое другое), формы редко меняются. В таком случае форма будет уже мгновенно вызываться
Концепция работы Data Providers на фронте:
На бекенде, это выглядит примерно также:
Итого мы имеем определение Data Provider - это интерфейс работы с данными внутри вашего приложения
И второе нужное нам определение FOR - это аббревиатура filters+options+response
Моё видение реализации
Data Provider имеет 2 механизма работы:
DataProvider::search($filters, $options, $response) статичный метод на входе, который покрывает 80% задач. Если всё в вашей системе представлено в виде элементов - то данный метод даст высший уровень гибкости вашему API, потому что позволит находить что угодно в рамках свои полномочий.
Также мы тут добавляем некий массив примитивных операций со статичным интерфейсом, когда фильтры избыточны, их может быть достаточно много и они также могут скрывать внутри себя фильтры, обеспечивая единообразие и одновременно упрощенный синтаксис.
Примеры:
CompanyProvider::get_by_id()
JobProvider::get_actual()
Конкретика
Архитектура состоит из 2 частей: пользователь и поставщик.
Поставщика я хочу детальнее описать позже, пока приведу пример реализации, который более нагляден
(код размещен в папке: DataProvider ElementSearch, эта часть будет подробно разобрана в другой статье) https://gitlab.com/dev_docs/software_architecture/for-architecture/-/blob/main/code_examples/DataProvider%20ElementSearch%20%5Bprototype%5D/BaseFilters.php
Концепция его работы:
:
Теперь взгляд со стороны использования:
Filters - определяет условия поиска (что и где ищем)
Options - определяет область поиска (все что не filter и не response)
Response - определяет модификацию / формат ответа (как обработаем ответ)
Примеры запроса будут размещены тут: https://gitlab.com/dev_docs/software_architecture/for-architecture/-/tree/main/code_examples/DataProvider%20ElementSearch%20%5Bprototype%5D/Examples
Реализация внутри системы (back / php)
(код размещен в папке: DataProvider ElementSearch, эта часть будет подробно разобрана в другой статье) https://gitlab.com/dev_docs/software_architecture/for-architecture/-/tree/main/code_examples/DataProvider%20ElementSearch%20%5Bprototype%5D
Фильтр - массив условий, фильтр состоит из:
object - объект поиска, состоит из:
element_type_id (element_type) - сама сущность (user, sku, company, news, properties ...)
element_id - подсущность. к примеру, id свойства или поле, к примеру: user_name или если props, то 69
operator_id (operator) - оператор поиска (у меня они все зарегистрированы и есть в виде констант, это лучше, чем их строковое представление) https://gitlab.com/dev_docs/software_architecture/for-architecture/-/blob/main/code_examples/DataProvider%20ElementSearch%20%5Bprototype%5D/Operators.php
value - значение поиска (может быть любой тип, все зависит от контекста)
Примеры фильтров:
DataProvider.search( { filters : [ { object : { element_type_id : _CONSTANTS.ELEMENT_TYPES.SOME_ELEMENT_TYPE_ID, element_id : 'some_id' }, operator_id : _CONSTANTS.OPERATORS.EQUAL, value : options.element_id } ] } )
PaymentProvider.search( { filters : [ { object : { element_type_id : _CONSTANTS.ELEMENT_TYPES.PAYMENT, element_id : 'payment_id' }, operator_id : _CONSTANTS.OPERATORS.EQUAL, value : this.element_id } ], response : { structure_mode : 'listing' } })
И немного посложнее
{ filters : [ { object : { element_type_id : _CONSTANTS.ELEMENT_TYPES.CATEGORY, element_id : null }, operator_id : _CONSTANTS.OPERATORS.EQUAL, value : 27 }, { object : { element_type_id : _CONSTANTS.ELEMENT_TYPES.ITEM_STATUS, element_id : null }, operator_id : _CONSTANTS.OPERATORS.IN, value : [103, 101] } ], response : { structure_mode : 'listing', add : { relations : [ { relation_id : 160, // связь - подчинённые relation_field : 'master', data_fields : 'IDS' }, { relation_id : 125, // связь с должностью relation_field : 'slave', data_fields : { general : ['item_full_name'] } }, { relation_id : 163, // связь с физическим лицом relation_field : 'slave', data_fields : { property : [ 18, // фамилия 389 // инициалы ] } } ] } } }
Именно это часть из архитектуры идёт в модель, а затем в БД (если речь про бек) или на апи (если речь про фронт).
Options - это специальные параметры, которые будут уникальны в каждом отдельно взятом продукте. Пояснение: В не релизном состоянии, когда код все ещё пишется и нет абсолютно точного описания задачи и конечной цели, когда не проработана вся комбинаторика - есть кейсы, когда в запрос надо добавить некие опции, чтобы получить результат (назовем это прототипный код, к примеру). Это место, куда вы можете пихать, пока не поймете как с этим быть.
Response - определяет тот формат (модель, дата-класс, ...) который вы хотите получить или, к примеру, вы хотите получить только ids элементов.
Дополнительный плюс этого подхода (как и любого другого, где есть сразу заложенная абстракция) - вы в любой момент без изменения бизнес логики сможете отказаться от реализации (которая в примере) и заменить её на более оптимизированный код (или даже отдельный сервис)
Немного рефлексии, для цельности картины:
Основные тезисы, которых точно стоит придерживаться в работе с данными
Абстракции - наше всё
Принцип единой ответственности (в чуть более широкой интерпретации) - должен быть в основе каждого вашего технического и не очень решения
Простота - во всём, простой код - легче понять и развить (исправить)
Бизнес логика и отдельные модули - не должны зависеть от поставщика решений (низкая связанность)
Каждое разрабатываемое приложение должно иметь четкую, единообразную структуру (но бывает много исключений)
