в смысле какой-то мудак в шиме заюзал неймспейс сустем? руки ему из жопы оторвать

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

внизу костыль

мдэ, а тот кто эту либу Shim писал вообще в адеквате был?)

Вроде не)

я бы задумался о том, чтобы не использовать такую либу)

если опенсорс то можно сурцы отрефачить и пересобрать

я тут почитал, shim это же для тестирования

походу тут упрлс тот, кто шимы и не шимы юзает вместе

Привет. Может кто по архитектуре приложения подсказать?

Подробнее

Вкратце, каким образом лучше разделить проект при таком кейсе.
Есть основная часть приложения рассчитанная на бизнес: статистики, аналитики, различные настройки и т.д. Условно CRM.
И есть часть приложения для клиента, которая дает возможность посмотреть инфу, написать отзыв, оставить заявку и т.д.

Для примера: сайт booking.com. Клиент может забронировать отель, имеет личный кабинет и т.д. Бизнес добавляет отели, фотографии, смотрит бронирования и всякое такое. Как я полагаю, данные одни и те же, но приложения разные.

Тут можно по разному и это всё равно будут правильные варианты.
Можно сделать сервис, отвечающий за данные и бизнес процессы и два отдельных веб приложения - одно для пользователей, другое для бизнеса.
Можно упихнуть это в одно приложение, внимательно следя, чтобы был один общий слой и два непересекающихся блока поверх него

Есть ли смысл разделять это на два разных приложения? Или можно сделать один проект со всей бизнесовой логикой?

Все это грубо говоря, опуская тонкости реализации. Вопрос про концепцию:)

Главное - чтобы доступ к конкретным данным был только через одно конкретное место в приложении - или через какой-то класс или через какой-то сервис - это необходимый минимум чтобы не огрести. А дальше наворачивай, как хочешь и как удобнее

Я пока для себя увидел такой вариант:
db - модель данных
utils - всякие атрибуты, экстеншены и прочие утилиты
core - бизнесовые модели и сервисы с основной логикой
client - эпп для клиента тоже с моделями и специфической логикой
business - тоже самое что и client

Из минусов вижу, что не всегда точно получится определить, что должно быть core, а что должно быть client/business.

Вроде бы microkernel подход такой называется.

Такое лучше рисовать, чтобы были видны зависимости между частями приложения

Существуют ли какие-то общепринятые практики проектирования таких систем? Я думаю, что кейс тривиальный: продукт для бизнеса с доступом к части данных извне.