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

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

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

интересно как это из названий ясно стало что тут сервисы, да еще и микро? %)

Какие сервисы, какие микро?:)

ойвей, ядро хотел написать, ну суть та же

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

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

вся эта хипстесркая блевотина с паттернами только усложняет простые вещи

Имхо, так тупо проще. + не будет смешиваться логика срм и клиентской части

особенно когда ее пихают во все дыры

У тебя общими будут:
1) модели
2) дтохи / poco
3) интерфейсы сервисов и абстракции
4) вью модели (возможно)
5) сервисы
6) какие-то спецификации и пр ерунда

А что насчет веб-приложения? Одно это приложение Web API например, или два?

Не понял вопроса

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