Ну и после тестов база же сама чистится если использовать фикстуры

Интересно, это как раз позволит избежать ручного создания дампа посленовых миграций

Давай :)

Вообще делают консольное приложение которое берет миграции и накатывает в тестовую базу.

То есть обычно делаем

./yii migrate

А там получится что то типа

./tests/bin/yii migrate

Оке в личку запилю

Спасибо!

о, я тоже такое несколько раз делал )

С точки зрения деления слоев (ddd) транзакции должны быть только на инфраструктурном слое?

И orm тоже

То есть если я хочу сохранить какие то допустим 2 сущности в рамках одной транзакции - я делаю в инфраструктуре в репозитории метод для сохранения этих двух объектов, да?

То есть никакого управления транзакциями выше инфраструктуры.

Наткнулася на тему на форумн Yii, прям по вопросу полезная дискуссия :) https://yiiframework.ru/forum/viewtopic.php?f=34&t=42166

Всем привет.

Делаю сервис уведомлений. В нем три канала доставки: смс, почта, в сервис.

Всё вроде бы шло хорошо. Сделал каналы, типы уведомлений, подписчиков. Как дошло дело до проектирования отправки и шаблонов писем, то немного зашёл в ступор... У меня есть сейчас система рассылки сообщений в ней тоже есть каналы рассылки: смс и маил. Шаблоны писем.

Вопросы:
1. Стоит ли проектировать в системе уведомлений реализацию отправки сообщений по каналам, шаблоны писем, не смотря на то, что они уже есть такие же в системе рассылки? Либо мне из системы уведомлений просто передавать в систему рассылки?
2.  Может быть объединить эти два сервиса, раз они так тесно связаны?

В сервисе

Сервис инфраструктурного уровня, которые будет вызывать репозитории?

Если ты используешь репозитории связанные с орм, то он будет в инфраструктуре, хотя лучше реализовать по-другому. В контроллере обернуть в транзакцию.

У меня система оповещения была === системе отсылки сообщений всегда.

Ну да, cycle orm.

В контроллере? Это там где обработка запроса от пользователя?

Можно сделать интерфейс репозитория и его реализацию, а уже внутри обращаться к сайкловскому репозиторию. Например:

class OrderRepository implements OrderRepositoryInterface
{
    //...
}

 
Такой репозиторий должен возвращать либо сущность, либо их коллекцию, либо их итератор, либо скаляр. В сервисы инжектится этот интерфейс. Все запросы к хранилищу идут через этот интерфейс. Он работает как апи, таким образом ты отвязываешься от конкретной реализации хранилища. То есть, у тебя сейчас заказы в основной rdbms, а ты решил вынести в нереляционную бд - нет проблем, сделал отдельную реализацию интерфейса и больше ничего менять не нужно. Хочешь вынести заказы во внешнюю систему - та же история, сделал отдельную реализацию интерфейса и заказы падают, скажем, сразу в 1с и оттуда же инфо по ним прилетает по api, опять же ничего больше менять не нужно.

class OrderRepository implements OrderRepositoryInterface
{
    //...
}

Это да, это я понимаю. Я не понимаю понятие транзакции... О них должен знать только инфраструктурный слой или же это понятие бизнес логики "сущность 1 и сущность 2 должны быть сохранены одновременно" и тогда можно на уровень usecases вытаскивать транзакции