Организация ядра и инсталятора

Центр управления доступом.
Собственно сам является ресурсом, так как может быть легко заменен на другую реализуцию этого модуля.
Отвечает за управление учетными записями, полномочиями, ролями, а так же аутентифицирует пользователя и информирует центральный контроллер о его правах. Очень удобным в этом модуле является то, что перед обращением к конкретному ресурсу, центральный контроллер спрашивает разрешение у центра управления доступом. Если для данного пользователя доступ к данной операции данного ресурса запрещен, центральный контроллер генерирует исключение.
Отдельной плюшкой здесь является то, что с помощью центра управления доступом можно запретить обращаться конкретному пользователю к конкретной функции ресурса, а к другой разрешить. Так, на пример, можно разрешить писать сообщения в гостевой только зарегистрированным пользователям, а удалять их только модераторам.
Плюсами этой структуры являются:
1) Заменяемость ресурсов без изменения кода
2) Расширение возможностей системы путем создания новых унифицированных интерфейсов классов ресурсов
3) Простая и гибкая политика безопасности
4) Независимость ресурса от центрального контроллера (достаточно реализовать контроллер ресурса)
5) Полная независимость представления от модели и обратно (полностью заменить как представление так и модели без изменения кода).
Как система реагирует на действия пользователей показано на этой модели http://upwap.ru/1944262
А теперь прошу снять с меня розовые очки и показать минусы. Громоздскость не в счет, ибо система вполне таки легкая, основным его элементом является центральный процессор, все остальное либо сторонние ресурсы (модули, бибилиотеки), либо визуализации.

Брр.. А может проблема в постановке изначальной задачи? Что же ты такое пишешь чтоб изобретать такой велодвиг? Распространенные фреймворки не справляются?

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

Добавлено через 01:18 сек.
Пишу довольно не маленький проект, который будет меняться чуть ли ни от клиента к клиенту, потому нужна максимальная гибкость и повторение кода

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

Это можно запросто реализовать в той же кохане. Добавляешь модуль управления модулями, в котором делаешь класс Modules и добавляешь ему метод is_installed(), соответственно делаешь учет установленных модулей в БД (это у меня в движке реализовано).
По твоему примеру, в инсталляторе модуля чата делаешь проверку зависимостей:

<?php

if ( ! Modules::is_installed($module))
{
    exit('Необходимо установить модуль '. $module);
}

Это всё, включая инсталляторы модулей, у меня реализовано в MC PRO, где используется один из распространенных фреймворков.

А как взаимодействие модуля с модулем и центр управления доступом? Моя реализация делает разграничение доступа прозрачным для любого модуля

Добавлено через 02:25 сек.
Я плохо знаком с коханой, но судя из твоего поста довольно много делать придется ) и так каждый раз?

Модули могут работать с моделями и другими классами других модулей, без каких либо ограничений и разграничений, не вижу в ограничениях какого либо смысла.

Добавлено через 01:28 сек.
> но судя из твоего поста довольно много делать придется ) и так каждый раз?

а с системами контроля версиями ПО знаком?)

Добавлено через 03:11 сек.
Мне никогда не приходится писать что-либо повторно, благо существует git и грамотная система переопределения кода в кохана + MC.

Знаком. Кохана с система взаимодействует и подстраивается под изменения? ) врядли. Потому и ввел унифицированный интерфейс группы ресурсов