Внутренняя архитектура проектов

Интеграция разных систем

Что такое хорошая архитектура?

работает как часы: ударил по ним - сломались

другой вариант - биологические системы

"Если бы космические модули обладали хоть частью инстинктов

обычной осы, у них никогда не возникало бы проблем с навигацией

при полёте на другие планеты"

Один из критериев - связанность системы

Хорошая архитектура:при изменении одного элемента

затрагивается только несколько связей

Плохая архитектура

Как это выглядит на уровне кода

много связей

мало связей

Рассмотрим концепцию на примере живой разработки

+

Что умеет TI если посмотреть снаружи ?

Показывать список стран и рекламу

Формировать фильтры

Искать туры с учетом фильтров

Отправлять заявку

Обычно внешняя часть проекта отвечает за:

Вывод статической информации (всякие списки, словари, реклама и т.п.)Вывод динамической информации (фильтры, результаты поиска чего-либо по фильтрам)Прием данных от пользователя и какие-то действия на это (авторизация, отправка заявок, сохранение блокнотов, закладок)

Для некоторых проектов - это реально все что он умеет.

Рассмотрим поближе как работали фильтры

В действительности всё не так как на самом деле (©VB) Мой пример сильно упрощен, реально фильтры сделаны сложнее

Что дальше?

А дальше менеджеры просчитают что мы сможем взять с клиентов NNN 000 - ую сумму бабла, если ....

Будем выводить в фильтрах некоторым пользователям определенных операторов

Вот во что превращается наша чудесная бизнес-логика:

И что в этом такого...?

Здесь наверно ничего, но посмотрим чем это оборачивается....

Немного истории

Долго треплюсь про то как мы делали TourDealer

Вот так мы это сделали

Все бы хорошо... но...Давайте теперь добавим еще одну проверку: light-версия TourDealer

в start.php в других файлах

Оказывается это не так просто

Приблизительно вот столько мест (54) придется поправить, и хорошо если при этом ничего не забудем

Как вы думаете откуда берутся баги?

Попросим внести необходимые правки того кто первый раз на проекте? :)

ООП нас спасет!

Глядя на все это безобразие, я решил добавить объектную модель на проект

Я попытался завернуть все эти проверки в объекты, чтобы в случае необходимости изменения настроек, изменения

происходили в одном месте.

Но я не додумал логику с пользователем и сетями, и .....

Вот к чему это привело....

Объекты чуть чуть упростили жизнь, но их начали использовать также как использовали глобальные переменные...

Посмотрите имена методов

Мы вернулись к тому от чего убегали....

Мы что-то делаем не так....

И в скоре я понял что!

Давайте еще раз посмотрим на шестой слайд.

Там нет сетевых пользователей!Нет мягкой франшизы!Нет лайт версии!

Система ничего не знает про них И НЕ ДОЛЖНА ЗНАТЬ!!!

Вот как надо делать

внешние настройки преобразователь ТИ

В данном случае:

Внешние настройки - это набор некоторых фактов типа пользователь является сетевым агентством, пользователь использует такое-то правило бронирования, пользователь работает с такими-то операторами, может отправлять онлайн-заявки и т.п.

Преобразователь - это объект, или группа объектов, которая переводит логику внешних настроек, например - "пользователь является сетевым агентством" в логику относящуюся непосредственно к ТИ - например "запрещена отправка заявок на email", "пользователь имеет доступ к бонусной программе"

Что у меня получилось

На деле не все так безоблачно... Но

Я добавил пользователю объект Ti_AgencyNetwork, который отвечает за параметры сети (если пользователь к ней относится)

Для пользователя я получил всего два параметра:

1. Ti_User::isNetworkMember() - фактически проверка на то что у пользователя есть объект сеть. Используется в основном при выводе имени сети :)

2. Ti_User::checkAccess('bonusProgramm') - проверка что у пользователя есть доступ к бонусной программе

Кроме этого в класс Ti_AgencyNetwork_Operators добавилось несколько дополнительных проверок является ли оператор онлайновым для данного пользователя (в зависимости от правила бронирования). Но внешне это ничего не изменило.

Также надо доработать класс комиссий чтобы он умел сам ее получать для сети.....

НО ЭТО ВСЕ! ТАМ БОЛЬШЕ НИЧЕГО НЕТ!

Это можно применять внутри любого проекта

внутренняя логика преобразователь

параметров

вывод

Самый простейший пример подобного преобразователя - это ACL.В нем внутренней логикой выступает пользователь, с его характеристиками, а логикой вывода - имеет пользователь доступ к странице или нет (код отвечающий за вывод запрашивает это у ACL).

Но не стоит ограничиваться этим.

Основное на что я возлагаю надежду - это то что после преобразования может получиться гораздо меньше настроек чем на входе.

Еще одна область - трансферы данных. Все знают что делать запрос к чужой базе данных - это плохо. Но также не обязательно трансферить всю табличку целиком в свою. Если вам скажем нужны данные по количеству фотографий, то трансферить можно именно эту информацию. А подготавливаться она будет там где эти фотографии заносятся в БД. Тогда при изменении структуру таблицы фотографий не придется ее менять ее на других серверах.

Еще один пример применения подходаРассказываю про архитектуру биллинга.

Смысл в том что пользователи оплачивают доступ в ТИ. Из чего абсолютно логичным на первый взгляд кажется связать пользователей CRM и пользователей ТИ. И проставлять некоторое свойство оплачено. Вопрос только как быть с оплатой показов рекламы.

После некоторого анализа можно понять, что CRM ничего не должен знать про ТИ, турпоиск, брокер. Отсюда вытекает такое понятие как "услуга". Которая на самом то деле и должна оплачиваться. Услуга и является этим самым преобразователем, связующим две системы.

Появляются услуги - "доступ в ТИ для аккаунта ....", "показ баннера на ТП с ... по ...". Они оплачиваются в CRM. А проекты уже проверяют оплату этих услуг.

Отсюда вытекает одно важное следствие - в этой модели доступ к аккаунту в ТИ, может оплатить другой пользователь! Например сеть может заплатить за свои агентства.

Всем спасибо!

Успехов!