Сейчас это работает через самораспакоковывающийся из массива JlobObjectInterface объект.

Самораспаковывают его геттеры и сеттеры на работу с объектом вместо массива намекает UoW что проект всегда поменялся (массив сменился объектом умеющим toArray). В итоге любой flush чего-то связанного с проектом приводит к его пересохранению. Что ужасно, но зато обновляет дату проекта.

Варианты решения:

• выделить слой бизнес-моделей в которые трансформеры будут выделать Проект со всеми его подобъектами. Но если я захочу его сохранять возникнет вопрос заного читать сущность? Искать её по своей реализации IM? Перебирать все поля в поисках изменившихся?
• не хранить в сущностях большие объекты, а вместо этого отдельный сервис их получения из сущностей (И, возможно кеширования)

Второй вопрос касательно именно TaskSettings сейчас он хранит справочники, но в будущем будет хранить всякое/разное. При этом src/Dictionary/Fetcher.php получает из него справочники некоторой магией, храня в src/Dictionary/TypesEnum.php набор методов которые нужно вызвать для получения справочника. Это типа полиморфно, но не очень явно. Хотелось бы, чтобы можно было обойтись от неявности и видеть все вызовы ->getTaskSettings и ->getStages явно. Так что лучше бы инстанцировать справочники фабрикой. Тем более что Fetcher уже стал весьма непростым и немаленьким, хорошо бы его распилить. Это будем решать в tndt-84

От задачи зависит tndt-30. она уже сделанна