обработали задачу или подзадачу - обновили джобу. Можно прогресс бары всякие пользователю показывать и вот это все..

а под копотом symfony/serializer + jsonb в базе

по-моему все эти три вещи не связаны друг с другом примерно никак
слои - это попытка декомпозиции по техническим признакам
read model - это данные предназначеные только для чтения клиентом (во всяком случае конкретная модель данных, потому что модели могут шарить данные, если контролем при записи занимается только 1 модель)
DDD - процесс выбора (выделения среди множества вариантов удобной?) модели предметной области

Job это отдельное понятие оно может основываться на очередях, на запланированном времени выполнения на определенное время и прочее job это не понятие очереди

у DDD нет слоев. DDD вообще не про код. Это про то "как ты выбираешь какая модель тебе нужна".

Не верно сказал

вьюшки в базе. самое простое.

У меня вот кейс есть - условно есть некий "профиль пользователя". тупой круд - мол имя там дата рождения... Хранится этот профиль как свалка jsonb документов с ревизиями. Поправил профиль - добавил ревизию. После этого в бэкагрунде из всех ревизий профиля формируется "вьюшка" для поисков всяких и т.д.

звучит как переабстрагирование) код ведь отражает/реализует концептуальную модель

что такое концептуальная модель и почему это "переабстрагирование"? Как ты определяешь пере или недо? 🤔

это артефакт процесса, процесс важнее.

грубо говоря если мы уж говорим про Write Model и Read Model то есть два основных момента при моделировании:

- Для Write model по сути мы говорим о том что данные консистентны и мы оперируем инвариантами.
- Для Read model - мы по сути говорим что "данные на момент просмотра могут устареть".

Важно какие вопросы ты задаешь при проектировании того или иного аспекта модели

например

вот у тебя есть скажем некая "команда" - хочу мол "зарезервировать чего-то". Эту команду пользователь запускает с некого UI. И тебе для построения рид модели для этого UI надо знать "а как он выбирает вообще че хочет сделать дальше?"

а слои - это булшит для детей.

по идее рид-модель можно и без вьюшек в базе сделать. Ну то есть резалт-сет полученный из той же таблички, в которой запись делается - это уже рид-модель

но если очень хочется - это все тот же domain layer

p.s. лучше думать в контексте port/adapter архитектур. у тебя есть некое "ядро" - приложение, модуль, компонент... внутри которого у тебя эти все агрегаты рид модели и тд. А снаружи реализации всяких интерейсиков которые ты хочешь он инфраструктуры. В том числе "клей" который разные модули соединяет.

Слои удобный концепт что бы на пальцах объяснять но они не оч хорошо скейлятся дальше.

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

ну и чем лучше оно друг на друга мэпится тем лучше)

в целом многие выделяют отдельный "слой" read model (тупо по направлению потока данных). но это даже не "слой" а скорее "папочка"