Архитектуре проектов на примере интеграции tourindex,...
TRANSCRIPT
![Page 1: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/1.jpg)
Внутренняя архитектура проектов
Интеграция разных систем
![Page 2: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/2.jpg)
Что такое хорошая архитектура?
работает как часы: ударил по ним - сломались
другой вариант - биологические системы
"Если бы космические модули обладали хоть частью инстинктов
обычной осы, у них никогда не возникало бы проблем с навигацией
при полёте на другие планеты"
![Page 3: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/3.jpg)
Один из критериев - связанность системы
Хорошая архитектура:при изменении одного элемента
затрагивается только несколько связей
Плохая архитектура
![Page 4: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/4.jpg)
Как это выглядит на уровне кода
много связей
мало связей
![Page 5: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/5.jpg)
Рассмотрим концепцию на примере живой разработки
+
![Page 6: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/6.jpg)
Что умеет TI если посмотреть снаружи ?
Показывать список стран и рекламу
Формировать фильтры
Искать туры с учетом фильтров
Отправлять заявку
![Page 7: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/7.jpg)
Обычно внешняя часть проекта отвечает за:
Вывод статической информации (всякие списки, словари, реклама и т.п.)Вывод динамической информации (фильтры, результаты поиска чего-либо по фильтрам)Прием данных от пользователя и какие-то действия на это (авторизация, отправка заявок, сохранение блокнотов, закладок)
Для некоторых проектов - это реально все что он умеет.
![Page 8: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/8.jpg)
Рассмотрим поближе как работали фильтры
В действительности всё не так как на самом деле (©VB) Мой пример сильно упрощен, реально фильтры сделаны сложнее
![Page 9: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/9.jpg)
Что дальше?
А дальше менеджеры просчитают что мы сможем взять с клиентов NNN 000 - ую сумму бабла, если ....
Будем выводить в фильтрах некоторым пользователям определенных операторов
![Page 10: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/10.jpg)
Вот во что превращается наша чудесная бизнес-логика:
И что в этом такого...?
Здесь наверно ничего, но посмотрим чем это оборачивается....
![Page 11: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/11.jpg)
Немного истории
Долго треплюсь про то как мы делали TourDealer
![Page 12: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/12.jpg)
Вот так мы это сделали
Все бы хорошо... но...Давайте теперь добавим еще одну проверку: light-версия TourDealer
в start.php в других файлах
![Page 13: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/13.jpg)
Оказывается это не так просто
Приблизительно вот столько мест (54) придется поправить, и хорошо если при этом ничего не забудем
![Page 14: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/14.jpg)
Как вы думаете откуда берутся баги?
Попросим внести необходимые правки того кто первый раз на проекте? :)
![Page 15: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/15.jpg)
ООП нас спасет!
Глядя на все это безобразие, я решил добавить объектную модель на проект
Я попытался завернуть все эти проверки в объекты, чтобы в случае необходимости изменения настроек, изменения
происходили в одном месте.
Но я не додумал логику с пользователем и сетями, и .....
![Page 16: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/16.jpg)
Вот к чему это привело....
Объекты чуть чуть упростили жизнь, но их начали использовать также как использовали глобальные переменные...
Посмотрите имена методов
Мы вернулись к тому от чего убегали....
![Page 17: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/17.jpg)
Мы что-то делаем не так....
И в скоре я понял что!
Давайте еще раз посмотрим на шестой слайд.
Там нет сетевых пользователей!Нет мягкой франшизы!Нет лайт версии!
Система ничего не знает про них И НЕ ДОЛЖНА ЗНАТЬ!!!
![Page 18: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/18.jpg)
Вот как надо делать
внешние настройки преобразователь ТИ
В данном случае:
Внешние настройки - это набор некоторых фактов типа пользователь является сетевым агентством, пользователь использует такое-то правило бронирования, пользователь работает с такими-то операторами, может отправлять онлайн-заявки и т.п.
Преобразователь - это объект, или группа объектов, которая переводит логику внешних настроек, например - "пользователь является сетевым агентством" в логику относящуюся непосредственно к ТИ - например "запрещена отправка заявок на email", "пользователь имеет доступ к бонусной программе"
![Page 19: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/19.jpg)
Что у меня получилось
На деле не все так безоблачно... Но
Я добавил пользователю объект Ti_AgencyNetwork, который отвечает за параметры сети (если пользователь к ней относится)
Для пользователя я получил всего два параметра:
1. Ti_User::isNetworkMember() - фактически проверка на то что у пользователя есть объект сеть. Используется в основном при выводе имени сети :)
2. Ti_User::checkAccess('bonusProgramm') - проверка что у пользователя есть доступ к бонусной программе
Кроме этого в класс Ti_AgencyNetwork_Operators добавилось несколько дополнительных проверок является ли оператор онлайновым для данного пользователя (в зависимости от правила бронирования). Но внешне это ничего не изменило.
Также надо доработать класс комиссий чтобы он умел сам ее получать для сети.....
НО ЭТО ВСЕ! ТАМ БОЛЬШЕ НИЧЕГО НЕТ!
![Page 20: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/20.jpg)
Это можно применять внутри любого проекта
внутренняя логика преобразователь
параметров
вывод
Самый простейший пример подобного преобразователя - это ACL.В нем внутренней логикой выступает пользователь, с его характеристиками, а логикой вывода - имеет пользователь доступ к странице или нет (код отвечающий за вывод запрашивает это у ACL).
Но не стоит ограничиваться этим.
Основное на что я возлагаю надежду - это то что после преобразования может получиться гораздо меньше настроек чем на входе.
Еще одна область - трансферы данных. Все знают что делать запрос к чужой базе данных - это плохо. Но также не обязательно трансферить всю табличку целиком в свою. Если вам скажем нужны данные по количеству фотографий, то трансферить можно именно эту информацию. А подготавливаться она будет там где эти фотографии заносятся в БД. Тогда при изменении структуру таблицы фотографий не придется ее менять ее на других серверах.
![Page 21: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/21.jpg)
Еще один пример применения подходаРассказываю про архитектуру биллинга.
Смысл в том что пользователи оплачивают доступ в ТИ. Из чего абсолютно логичным на первый взгляд кажется связать пользователей CRM и пользователей ТИ. И проставлять некоторое свойство оплачено. Вопрос только как быть с оплатой показов рекламы.
После некоторого анализа можно понять, что CRM ничего не должен знать про ТИ, турпоиск, брокер. Отсюда вытекает такое понятие как "услуга". Которая на самом то деле и должна оплачиваться. Услуга и является этим самым преобразователем, связующим две системы.
Появляются услуги - "доступ в ТИ для аккаунта ....", "показ баннера на ТП с ... по ...". Они оплачиваются в CRM. А проекты уже проверяют оплату этих услуг.
Отсюда вытекает одно важное следствие - в этой модели доступ к аккаунту в ТИ, может оплатить другой пользователь! Например сеть может заплатить за свои агентства.
![Page 22: Архитектуре проектов на примере интеграции TourIndex, TourDealer](https://reader034.vdocuments.pub/reader034/viewer/2022042518/5598cc221a28ab731a8b4629/html5/thumbnails/22.jpg)
Всем спасибо!
Успехов!