Adamos

Я бы разложил проблему на отдельные задачи и не смешивал их без необходимости.
Очевидно, нужна общедоступная веб-морда для записи с актуальными данными. Но совершенно незачем держать на том же сервере конфиденциальную информацию. Тем более, что она должна быть доступна в клинике даже при отключенном интернете.
Имеет смысл создать несколько изолированных, но общающихся между собой узлов - скажем, веб-морда в интернете и веб-морда на внутреннем сервере, с которой работают сотрудники, но она не торчит в интернет. Внутренний сервер запрашивает у сайта, что там с расписанием, но связь односторонняя, и взлом или отвал интернета ничего всерьез не нарушит. Внутренние сервера нескольких клиник поддерживают общую базу, но уже неспешно, без завязки на постоянный аптайм...

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

Тут такое дело: паттерны - это способы взаимодействия классов, а не метод написания самих классов.
Если вы нормально пишете классы, соблюдая SOLID, то для вас не будет большой проблемой наладить между ними взаимодействие, используя тот или иной паттерн, и переписывать основной код не понадобится.
Если же вы просто фапаете на GoF и пытаетесь вымучить в коде свои представления о том, как вы их поняли, мужественно преодолевая ООП - все равно получится говнокод, который придется несколько раз переписывать для вменяемой работы. Так что на этом этапе паттерны скорее вредны.

"Ну конечно, естественно, само собой разумеется - нет!" (Гэндальф в русском переводе).
Эта область называется "инкапсуляция", и это самые азы архитектуры.

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

/vendor/{your_company}/{project}?

Если имеется в виду именно интерфейс, а не архитектура, то вам нужно заклинание "Human Interface Guidelines". Можно начать колдовать с Википедии.

> способ сделать плоским наследование групп типа "manager может делать всё то, что и customer, но ещё вон то и вот это"? Резоннее и более поддерживаемо будет дублировать все права?

Имхо, все эти заморочки с наследованием групп нужны только для удобства администрирования. И место им - в админке, а не в группах. Сделайте удобное редактирование групп, со сравнением с другой группой. Или шаблоны, позволяющие применить пользователю сразу несколько групп. Даже более сложные вещи типа того, что группа менеджеров не может быть применена в отрыве от кастомеров.
Но все это - не в группах, а именно в этом разделе админки. Назначаются-то группы далеко не так часто, как используются. А вот для использования им стоит быть максимально простыми.