Да, ситуация у вас тяжелая была. Конечно, обращение к HTTP Request в модели это перебор. И я тоже против повсеместного обращения к реестру. Но вот в конструкторе, при инициализации объекта, на мой взгляд, допустимо обращаться к реестру за зависимостями. Если там будет обращение к недоступной зависимости, это быстро обнаружится, так же как и для классического конструктора. Также API класса для использования в клиентском коде становится попроще — не надо всюду все зависимости для создания экземпляров прокидывать.
Я раньше тоже был только за классическое внедрение через конструктор/методы, но сервис-локатор в конструкторах упрощает код и экономит время. К тому же зависимость можно прокинуть туда, куда ее через конструктор иногда не прокинешь (какая-нибудь библиотека требует, чтобы он был без параметров).
Безусловно, у классического внедрения свои плюсы — можно класс сделать независимым от локатора — максимально реюзабельным. Но это не всегда нужно.
А почему вызовы save() в методах-мутаторах (изменяющих состояние) AR считаете неправильным? И причем тут сильная связанность? Я как раз наоборот, ратую за это. Тем более в Yii, если ничего не поменялось, то к базе запросов не будет.
Я думаю, что это абсолютно нормально, когда для решения какой-то задачи берется популярный, поддерживаемый фреймворк и код зависит от него. В этом ничего плохого я не вижу и считаю это нормальным. Да, при смене мажорной версии придется приложить усилия, заменить какие-то вызовы, базовые классы, отрефакторить проект. C DDD эти усилия прикладываются наперед, но несколько в другом виде — абстракции. домена. Но и это спасет от рефакторинга лишь часть проекта. При замене фреймворка/мажорной версии все равно придется много переделывать. Инфраструктурный слой все равно придется переписать, а этот слой чаще получается даже намного толще доменного.
Я предпочитаю не закладывать наперед возможность смены фреймворка/мажорной версии, так как это порождает много абстракций, которые замедляют и усложняют разработку (надо больше думать для выделения хороших абстракций), чтобы потом облегчить гипотетическую смену фреймворка, которая может и не понадобиться вовсе. Некоторые проекты на Yii1 спокойно продолжают работать.
Фреймворконезависимость обходится дорого, она добавляет забот. Помимо реализации требований, приходится решать задачи по абстракции.
Да, иногда, она оказывается полезной, но я нахожу такие ситуации довольно редкими.
Я хотел сказать, что любые приложения всегда пишутся по требованиям бизнеса, DDD здесь не монополист. Да, по сравнению с обычными приложениями, в DDD код более абстрактный и иногда легче по нему понять сложную бизнес-схему. Но это актуально только для реально сложных проектов, там где логика простая, DDD привносит больше сложности, чем снимает. Основная цель DDD борьба со сложностью, но для этого нужно сначала убедиться в том, что эта сложность действительно есть и она будет доставлять проблемы.
Скажем, в типичном Yii/Laravel приложении бизнес-логика очень часто размазана между контроллерами (классами унаследованными от базового класса контроллера) и «моделями» (классами, унаследованными от базового класса ActiveRecord). И хорошо если бОльшая часть в «моделях», а не в контроллерах.
Ну в таком случае можно сказать, что в DDD-проекте она размазана между сущностями и сервисами, и хорошо, если большая часть в сущностях, а не сервисах, чтоб не получились анемичные сущности.
«То же самое» — имеется ввиду реальная работа, которую выполняет код. Да, абстракция стала сильнее, но внедрять новые функциональные возможности, как ни странно, стало сложнее. Приходится думать, как новое ляжет на существующие абстракции, а если не ложится, приходится их модифицировать вместе со всем соответсвующим инфраструктурным кодом. Да и просто больше файлов надо просмотреть и отредактировать.
Сначала меня DDD увлек, я думал, он мне поможет упростить работу, а на практике оказалось нет. Проект не настолько сложный и большой, команда 3 человека в одном офисе.
Несколько лет назад, мы потратили 4 месяца, на проектирование архитектуры доменого слоя для SF без кода.
4 месяца без кода, ну это большой риск. И что прототипов даже не писали?
На данный момент, проект полностью оторван от приложения. Т.е. домен можно использовать в любом другом месте, подгрузив только нужные зависимости.
Вот именно, что можно, но нужно ли? Вам это дало какой-то профит, если не секрет, какой? Повторно использовали домен в другом проекте? Так он же уникальный, разве нет? В чем именно получилась реальная выгода, если не секрет?
Я пробовал применять DDD в проекте. Что получилось — то же самое что и было без DDD, только работы больше по абстракции домена. Кода стало реально больше. Оверхед был налицо, поэтому для себя я сделал вывод, что DDD нужно применять только тогда, когда есть проблемы коммуникации(!), домен реально сложный и нетиповой.
Главная цель DDD это устранение сложностей с пониманием предметной области и создание реализации, максимально близкой к модели предметной области, чтобы ее удобно было понимать и поддерживать.
По вашему серьезные проекты невозможны без DDD?) Большинство проектов на Yii не сделаны по DDD, их вы тоже не считаете работой?) Жгите дальше.
Проектов настолько больших, чтобы DDD принес реальную пользу (ЧСВ не в счет) немного, так что ниша Yii/Laravel довольно большая.
IoC есть и в Yii и в Laravel. В Yii в основном практикуется ServiceLocator. например вызов Yii::$app->get(); или Instance::ensure() в init() или конструкуторе хуже классического внедрения только в том плане, что нельзя будет класс оторвать от фреймворка, а это не так уж нужно если не пишешь библиотеку.
Да, Yii/Laravel + VueJs на мой взгляд сейчас очень актуальный и востребованный стек.
Сам работаю с Yii, очень удобно.
Про механизмы доступа к данным что-то ничего не написали.
Hot reload'ом во всех случаях не отделаешься. Он не всесилен и не вся конфигурация через него меняется. Это отговорки. Админ, который ребутнет сервер, может и не знать, что что-то потом надо переиндексировать.
Если вы сервер бд стопанете у вас элементарно сайт работать не
будет.
Тут дело в моменте остановки — именно в этот момент может много чего в базу и в индекс писаться, что приведет в вашем случае к неконсистентности. Или так по-вашему тоже не бывает?
Но тк. Solr это вторичное хранилище, вспомогательное а никак не основное то это приемлимо и решается переиндексацией.
Тгда уж лучше по крону с дельтами все индексировать и следить «не рассинхронизировался ли индекс» не надо. Кто за этим будет следить?
Таким образом, я вижу два отказоустойчивых решения. Первое — полностью индексировать все данные по крону, можно с дельтами. Второе решение — с доп. таблицей с событиями и другим процессом. Второе можно не обязательно по крону — можно и демона написать, который будет поллить таблицу, будет near real time. Ну или cron раз в минуту). И первое и второе реализуется легко. Попробуйте.
Но как часто это случается и даже если это случилось идете и запускаете переиндексацию и всё.
Вот он, авось). Это можно если вы на одном проекте сидите. А если не вы будете поддерживать? За каждым следить? Нет уж, пусть лучше само восстанавливается. А в чем конкретно сложность приведенного мной решения?
У нас 2PC между таблицей log в РСУБД и индексом solr. Фаза подготовки — вытаскиваем событие из таблицы log, индексируем в solr. Фаза фиксации — записываем в РСУБД, что событие обработано. Если фейл произойдет на фазе подготовки по причине отказа недоступности solr — операция повторится. Если на фазе фиксации — тоже повторится. Консистентность гарантирована. Да роллбека в solr нет, но он не обязателен для 2PC — там главное обеспечить согласованность и мы ее сохраняем при таком подходе. Индекс Solr идемпотентен — можно записать второй раз, ничего плохого не случится.
Ну назвали бы эти «причины». Основная причина наличия журнала — возможность восттановления после сбоя до определенной точки — обеспечение согласованности. Зачем дублировать? Затем чтобы обеспечить согласованность в конечном счете между солром и данными в БД. И вы сами признали то, что решение с доп. таблицей обепечивает надежность даже в случае аварийных остановов. Понятно зачем дублирование?
Я раньше тоже был только за классическое внедрение через конструктор/методы, но сервис-локатор в конструкторах упрощает код и экономит время. К тому же зависимость можно прокинуть туда, куда ее через конструктор иногда не прокинешь (какая-нибудь библиотека требует, чтобы он был без параметров).
Безусловно, у классического внедрения свои плюсы — можно класс сделать независимым от локатора — максимально реюзабельным. Но это не всегда нужно.
А почему вызовы save() в методах-мутаторах (изменяющих состояние) AR считаете неправильным? И причем тут сильная связанность? Я как раз наоборот, ратую за это. Тем более в Yii, если ничего не поменялось, то к базе запросов не будет.
Я предпочитаю не закладывать наперед возможность смены фреймворка/мажорной версии, так как это порождает много абстракций, которые замедляют и усложняют разработку (надо больше думать для выделения хороших абстракций), чтобы потом облегчить гипотетическую смену фреймворка, которая может и не понадобиться вовсе. Некоторые проекты на Yii1 спокойно продолжают работать.
Фреймворконезависимость обходится дорого, она добавляет забот. Помимо реализации требований, приходится решать задачи по абстракции.
Да, иногда, она оказывается полезной, но я нахожу такие ситуации довольно редкими.
Ну в таком случае можно сказать, что в DDD-проекте она размазана между сущностями и сервисами, и хорошо, если большая часть в сущностях, а не сервисах, чтоб не получились анемичные сущности.
Сначала меня DDD увлек, я думал, он мне поможет упростить работу, а на практике оказалось нет. Проект не настолько сложный и большой, команда 3 человека в одном офисе.
Извините, я неправильно понял ваш комментарий.
4 месяца без кода, ну это большой риск. И что прототипов даже не писали?
Вот именно, что можно, но нужно ли? Вам это дало какой-то профит, если не секрет, какой? Повторно использовали домен в другом проекте? Так он же уникальный, разве нет? В чем именно получилась реальная выгода, если не секрет?
Вот, сразу виден фанатизм. Он ослепляет.
Я пробовал применять DDD в проекте. Что получилось — то же самое что и было без DDD, только работы больше по абстракции домена. Кода стало реально больше. Оверхед был налицо, поэтому для себя я сделал вывод, что DDD нужно применять только тогда, когда есть проблемы коммуникации(!), домен реально сложный и нетиповой.
О недостатках DDD в википедии
По вашему серьезные проекты невозможны без DDD?) Большинство проектов на Yii не сделаны по DDD, их вы тоже не считаете работой?) Жгите дальше.
IoC есть и в Yii и в Laravel. В Yii в основном практикуется ServiceLocator. например вызов Yii::$app->get(); или Instance::ensure() в init() или конструкуторе хуже классического внедрения только в том плане, что нельзя будет класс оторвать от фреймворка, а это не так уж нужно если не пишешь библиотеку.
Сам работаю с Yii, очень удобно.
Про механизмы доступа к данным что-то ничего не написали.
Тут дело в моменте остановки — именно в этот момент может много чего в базу и в индекс писаться, что приведет в вашем случае к неконсистентности. Или так по-вашему тоже не бывает?
Тгда уж лучше по крону с дельтами все индексировать и следить «не рассинхронизировался ли индекс» не надо. Кто за этим будет следить?
Вот он, авось). Это можно если вы на одном проекте сидите. А если не вы будете поддерживать? За каждым следить? Нет уж, пусть лучше само восстанавливается. А в чем конкретно сложность приведенного мной решения?