Михаил, если вы имеете ввиду транзакционность как возможность отката цепочки процессов, то соглашусь с этим, но это отличается от транзакций на уровне субд.
Транзакционность как правило это задача сервисного слоя.
может промокод существовать отдельно от заказа?, могут ли в заказе быть позиции заказа, могут позиции существовать отдельно от заказа наверно если не могут то 100% агрегат
товары - скорее всего товар может существовать отдельно от заказа, может ли товар быть без раздела наверно нет, может ли раздел бы без каталога, тоже наверно нет. эти вопросы нужно задавать при проектировании в первую очередь.
в приведенном примере можно выделить два контекста: Заказ и Каталог
в контексте заказа существует Агрегаты: Заказ, наверно могут быть также Покупатель, Доставка, Оплата как отдельные агрегаты так как доставка может быть без заказа
в агрегатах связи с другими агрегатами могут быть по uuid
например в заказе есть связь с покупателем order->shopperId = 1; а может быть объект order->shopper->getName()
у покупателя связь с заказами может быть Shopper->orders = [123,123]
позиция заказа может иметь связь с товаром OrderPosition->productId = 123;
из последних интегрировал с битрикс24 и с мойсклад
все очень просто, не думаю что сложно реализовать на любом другом движке, делал кстати для аналогичного сайта клиенты,поставщики,продажи,опт
тут вопрос как сделать и не сломать последующие обновления CMS
unit тесты - они же модульные, их много, работают быстро, запускаются на каждый коммит в репо, используется покрытие кода, используются в инфраструктурных библиотеках для повышение стабильности , а также в приложении в важных бизнес кейсах.
интеграционные тесты - для тестировании необходимо поднимать бд, тестируется цепочка процессов, кейсы, оформление заказа, регистрация и тд. работает медленней, тестировать можно на каждый релиз в редких случая на каждый коммит.
приемочные тесты - тестирование GUI, в разных браузерах, работает очень медленно, тестов по % меньше всего, зайти на страницу, заполнить форму, нажать кнопку и тд. тестируется на каждый релиз
опять же у вас есть класс который вы мокаете, назовем его $this->currencyRateService->getRates();
сегодня вы получаете данные с http сервиса, завтра вы переведете получение данных из файла или из бд.
нужно ли вам каждый раз во время ваших тестов тестировать подключение к бд/файловой системе/внешнему сервису, нет, это задача других тестов
если пакеты и модули одно и тоже то в моем понимании это контекст, например Контент, или Блог.
Соответственно в этом контексте-пакете будет логика работы с постами и новостями, юзеры и комменты. Думаю что вас смущает что этот же юзер будет использоваться в другом пакете, например в пакете авторизации/аутентификации.
так вам необязательно хранить в пакете реализацию вашей модели.
например там можно будет встретить как AuthorInterface, PostInterface,CommentInterface
например сервис получения статьи
class PostService
public function getById(): PostInterface {
где у сущности PostInterface в свою очередь будет
public function getAuthor(): AuthorInterface;
потом у вас будет папка для инфраструктурного кода там будут ваши реализации интерфейсов, созданных с помощью фраймворка
class UserModel impliments AuthorInterface, UserInterface
