Классы, не относящиеся к данным, являются частью модели?

Модель домена - это данные, относящиеся к домену. Он может исходить из любого источника, может быть одним способом (например, рассчитываться и сохраняться только и никогда не читать). База данных - это стратегия сохранения только одного домена.

Итак, да, данные из разных мест могут быть частью модели домена.

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

Это зависит.

Если эти классы представляют собой комбинацию данных, поступающих из разных таблиц, обрабатывают данные, принимают решения и организуют операции, я бы рассмотрел их сущности бизнес-уровня и сохранил их на бизнес-уровне.

Если это какие-то помощники, это будет зависеть.

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

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

С "StatusMessage" может быть необязательно иметь для этого отдельный класс. Сообщения относятся к уровню представления. Класс может просто решить, какое сообщение показывать, но тогда реальная работа дисплея будет проходить ближе к пользовательскому интерфейсу.