Архитектурный вопрос.

Есть у вас проект.
Есть у вас слой приложения.
Есть у вас слой UI.
Есть у вас слой логики/транспорта/чего-то ещё.

И вот где-то в недрах у вас происходит нечто, что надо отобразить в UI.

Вот прям сейчас в проекте я делал так: приложение управляет объектами, тут же проверяет какие-то их параметры, и если что, то делает отметки в UI.
А потот я решил сделать "правильно" и выкинуть весь этот код из слоя приложения. Потому что уж много там делализаций получается.

То есть было, грубо если, так:
Приложение управляет объектами 1-го уровня, получает от них объекты 2-го уровня, от них 3-го уровня и делает выводы.

Стало:
Приложение работает с объектами 1-го уровня. Объекты любых уровней, если что случилось, собирают нотификацию, отправляют её родителю, он лепит свой id в хвост и отправляет выше, и так далее. Отправка - просто вызов функции с vector<string> ref. На верхнем уровне приложение парсит вектор и делает действия.

Какие есть варианты для такой архитектуры? Этот тоже норм?

Он есть, тут вопрос был про сам Document и нотификации внутри него.
Я неудачно использовал понятие "слой". Давайте я на примере покажу.
У меня есть танк. Есть игра(приложение), которая рулит UI. У танка есть внутренние объекты, типа "оружие", одно из них пушка. Танк едет по полю и собирает ящик с особыми припасами, 20 штук.
Тут надо на UI это отобразить, нарисовать значок и 20. А по мере стрельбы, цифру уменьшать, когда будет ровна нулю, значок убрать.
Как было: игра на каждом шагу лезет в танк, находит у него пушку и в пушен проверяет количество особых припасов - изменяет UI.
Как стало: пушка, когда получает/теряет припасы, собирает нотификацию для танка, танк передаёт её в игру, игра делает отметки в UI.
Т.е. есть иерархия классов, и где-то на нижних уровнях объекты хотят оповестить приложение на самом верху.
А можно как-то на примере показать? я не совсем понял.
Ну, как бы, да, в общем случае, но тут просто нет очереди, а нотификация сразу приходит в приложение. Я сначала подумал про очередь, а потом подумал - а зачем? Только лишние сложности, функционал, который мне не требуется, а только может всё усложнить. Мне надо только универсальным образом оповестить приложение.
Нет, у меня всего этого нету. Но первый пункт теоретически возможен, надо будет про это подумать, спасибо.
Ну, кстати, я тему завёл частично для всем поделиться полезными практиками, опытом.
Да ну не всегда :) Я стараюсь один раз писать с нуля, потом этот код использовать
А вообще, я вот смотрю на плюсы и на яву, для меня вот загадка, как в яве так получается, что все про все библиотеки знают? А с плюсами не так, я читаю телеграмчик, и там постоянно дают ссылки на какие-то полезные вещи, про которые я вообще не знал.

Да это просто пример был, есть приложение, есть объекты, есть объекты в объектах, надо проинформировать приложение о смене состояния.
Но да, я свои танчики делал, лет 8 назад, было такое. На рсдн-е даже есть видео одного забавного бага про останавливающиеся ракеты. Весёлое было времечко :)
А если я недоволен, то как надо сделать?
Код стал удобнее. Приложение пинает только объекты верхнего уровня.
это был пример :) Но, кстати, судя по всему, все любят игры, раз такой интерес сразу.

Меня вообще интересовал паттерн для этой задачи, какой обычно используется?

Ещё раз расскажу:
- Приложение оперирует объектами класса A, класс A содержит объекты класса B, объекты класса B не имеют доступа к Приложению, но должны его информировать о некоторых событиях.
- Вариант 1. Приложение при управлении объектами класса A, само опрашивает дочерние объекты класса B на тему изменения состояния.
- Вариант 2. Объекты класса B в случае изменения состояния, собирают нотификацию и отдают её родительскому объекту класса A, а тот пересылает его Приложению.

Что хорошо, что плохо, как правильно?

Ну оно ответственное за UI, потому и берёт.
Плохо: карта лезет напрямую в UI. Ей надо знать про UI, она привязана к UI.
Хорошо: можно сделать такое архитектурное решение, в котором объекту нижнего уровня можно привязать объект из UI(не напрямую), чтобы он сам им рулил, когда надо. Совсем хорошо подходит, когда 1:1. У меня 1:1. Поэтому я теперь задумался про изменения в архитектуре. Ну и у этого тоже есть плюсы и минусы. Плюс, что "прикрепил и забыл", не надо больше думать об обновлении. Минусы - надо проводить дополнительные шаги при инициализации, заботиться о том, что UI подходит данному элементу, следить за тем, что будет, когда один из этих двух закончится и так далее.
В JS всё хорошо на вид, ну, собственно, это и есть мой второй вариант, когда объект нижнего уровня начинает отправлять наверх сообщение, оно проходит через всю иерархию, до document.

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

Да я тоже люблю строгую типизацию, но если классов для нотификации становится слишком много, то отношение смысла к количеству кода начинает стремиться к нулю, и ещё вся эта толпа мельтишит в окне проекта. А это я уже не люблю :)