Если вы хотите построить хорошую архитектуру, то должны проектировать ПО исходя из best practice (классика по типу SOLID, DRY и т.д.) В данном случае мне не очень понятно за что отвечает класс Messager. Если это обобщенный класс одной беседы, то тогда логичным было бы хранить данные о собеседниках и сообщениях в объекте данного класса (если вы предполагаете наличие больше, чем одной беседы).
Также, если вы хотите усложнить приложение, то логичным выглядит создание классов-интерфейсов (для обмена сообщениями, т.е. отправкой, сохранением, работой с базой данных). Вот паттерны, которые могут быть полезны в случае задачи именно с кешированием базы данных (
proxy,
chain of responsibility).
В самом простом случае, вы действительно можете создать основной класс меседжера и хранить лист из объектов класса беседы, в которых есть листы объектов класса сообщения.
Вариант сохранения данных в классе (вместо объекта класса) заставляет задать вопрос (особенно, если задачка учебная) о возможности создания двух объектов данного класса и целесообразности этого. В случае же, если объект данного класса будет лишь 1 (aka
паттерн singleton), то нет необходимости хранить данные в классе, это будет даже вредно, поскольку без самого объекта эти данные не имеют смысла.
P.S. Я никакой не эксперт в архитектуре, это лишь мое видение и чуточка опыта.