Архитектура: несколько сайтов. Одна кодовая база. Пользовательский код

Question

Хорошо.В настоящее время я создаю php-приложение (платформу), которое будет развернуто несколько раз, только с разными конфигурациями.Приложение состоит из бэкэнда и внешнего интерфейса.Через бэкэнд мы можем настроить, какие модули активны, какие есть настройки и как выглядит платформа.

Мы ожидаем, что клиенты начнут запрашивать конкретные функции на своей платформе.Это означает, что там платформа будет отличаться от других.Но мы поддерживаем одну кодовую базу.

Какой лучший способ решить эту проблему?Так как мы продолжаем исправлять ошибки и разрабатывать новые функции, должно быть легко позаботиться о всех платформах.У нас есть скрипт, который мы используем для развертывания обновлений нашей платформы на всех наших платформах.

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

Или мы должны писать исключения в коде для каждого клиента?

Должны ли мы иметь отдельные файлы, которые переопределяют базуфайлы для каждой платформы с пользовательским кодом?

Какой лучший путь?

Answer 1

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

• Инверсия зависимости : есть много материала на эту тему, в основном это способ структурирования системы так, чтобыразличные части в нем зависят от концепций, а не от конкретных реализаций.Это позволит вам поменять эти реализации для разных клиентов.Его можно использовать для всего: от глубокой бизнес-логики и алгоритмов до провайдеров данных и виджетов пользовательского интерфейса.Я не уверен, где лучше всего начинать с DI (и я пришел из .Net фона, а не из PHP), поэтому вот запись в Википедии в качестве начала.
• Определитьвиды вещей, которые пользователи захотят изменить и изолировать эти вещи в вещи, которые могут быть легко заменены с помощью DI или другого практического подхода.Сделав это, постарайтесь не вносить изменений в кодовую базу фреймворка (ядро, которое в основном «размещает» заменяемые биты.
• Сохраняйте дерево зависимостей как можно более чистым.
• Началос PoC / Prototype. Построение фреймворков очень сложно. Ваша первая попытка может работать нормально, но ваши вторая и третья попытки будут лучше, опыт имеет большое значение.
• Приложите некоторые усилия для упрощения тестирования системы.как во время разработки, так и после развертывания. Со всеми движущимися частями вам потребуется хорошая диагностика, которая поможет вам изолировать проблемы и помочь с интеграцией.

Редактировать : Наконец, если вы 'Если вы еще не знаете о них, существуют существующие PHP-фреймворки, которые вы можете использовать или просто позаимствовать у них - сообщество PHP с открытым исходным кодом довольно сильно. Ознакомьтесь с Zend Framework.