Во время написания ответа, примите во внимание тот факт, что я лишь начал учить веб разработку, укажите пожалуйста более развернутый ответ на всевозможные "костыли".
Пришла на ум структурировать некоторые библиотеки в один пакет (назовем его Core). В его состав входят библиотеки
Events,
Fstream(работа с файловыми потоками),
Errors(собственно обработка ошибок),
Logger(ну тут думаю понятно). Я решил их завернуть в один пакет в связи с тем, что каждая библиотека использует другую библиотеку из пакета. Мне показалось это хорошим тоном, структурировать их, задать логику (
Ядро автономно, оно должно уметь работать с автозагрузкой и логгировать исключения, вне зависимости от того, есть для этого готовая библиотека. Ядро всегда уверено, что в его составе есть функционал для корректной работы, чего нельзя точно сказать, при сборке приложения из готовых сторонних библиотек).
Планируется, что ядро можно без изменений использовать в разных проектах, просто дописывая нужные библиотеки использующие API Ядра.Вывод: В ядре сконцентрирован базовый функционал, который используется для создания любого веб приложения, все остальное - внешние библиотеки, которые могут использовать API ядра для расширение его возможностей и т.д.
Встал вопрос о том, как получать экземпляры классов входящих в состав ядра и работать с ними на уровне приложения.
Создание через new Lib() у меня вызывает некоторое отторжение, поскольку на глаз не виден тот факт, что указанный Lib принадлежит к пакету ядра, в следствии чего меня посетила идея, использовать своеобразный транспортный слой, по синтаксису будет проще объяснить
$lib = Core::resource('libname', $constructorArg1, $constructorArg2...) //@return Object libname
//Это же далеко не DI или IoC?
Добиться того, чтоб переменные передавались в конструктор не через function_get_args() я решил использовать интересную конструкцию php 7 ниже пример по ссылке
<?php
function sumOfInts(int ...$ints)
{
return array_sum($ints);
}
var_dump(sumOfInts(2, '3', 4.1));
$lib = Core::resource('libname', $constructorArg1, $constructorArg2...) //@return Object libname
//Это же далеко не DI или IoC?
Вот такое хочу использовать, чтобы код стал читабельнее и чтобы жестко указывать, что libname ищется как библиотека ядра.
У меня пока нет опыта разработки, а начинать продакшн с костылей не хочу, вот и прошу внятную критику архитектуры
Вот пример зависимостей библиотек:
Core - использует сервис отлова ошибок ErrorTrap который задействует logger и Report для логгирования и отправки отчетов
- использует Event чтоб сообщить слушателям, об успешной инициализации ядра
Собственно дерево каталогов пакета Core
