фабрики, билдеры и т.д. - это просто паттерны. Их роль могут брать другие сущности. Особенно для фабрик это распространенная штука. Ну так, просто что бы чуть расширить фантазию.

Например я вот выше приводил пример - $approvedReview = $review->approve() - в этом случае approve это такая простая фабрика для ApprovedReview.

в целом нет смысла в билдере который просто данные собирает и никаких ограничений не накладывает. Обычно в этом их польза. Проверить все перед тем как создать сложнйы агрегат.

Но я стараюсь обычно избегать такого. Обычно это запашек что слишком много всего. Хотя бывают кейсы (я просто сходу не придумаю) когда это надо

Фабричные методы это да, с ними я разобрался. Интересует именно конструирование сложных объектов

Просто сейчас не знаю, если я создаю объект через билдер, то объект сам себя получается не защищает. Получается скрытое правило, что создаём через билдер. Но обязать нельзя.
Дублировать правила тоже не хочется

Это с вариантом, когда Бизнес правила уезжают в билдер

ну если правила дублируются то это не хорошо, надо начинать думать зачем понадобился билдер)

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

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

все ж у этого всего цель то одна - упростить восприятие логики (что б читал код и понятно что происходит) и защита от дурака. Если код становится сложным и ты не ощущаешь профита - нафиг это надо

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

на самом деле у меня в голове каша, у меня есть:

1) набор паттернов для микросервисов: https://microservices.io/patterns/index.html
2) набор моделей консистентности, часть из которых транзакционные, хотя у меня не все компоненты поддерживают транзакции https://jepsen.io/consistency

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

Прочитайте книгу Ричардсона по паттернам и рефакторингу микросервисов

А вообще подобие транзакций делают вручную сагами, которые ловят события из одних сервисов и запускают нужные команды в других.

> чтобы при этом не получилась переусложнённая дичь

Не переживайте. С шестого раза получится лучше :)

ок, спасибо)

Понапридумывают своих микросервисов, а потом борятся с ветряными мельницами 😅

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

Какие гарантии в них спрограммируете, такие и будут.

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

двухфазные коммиты, транзакции, а вы точно микросервисы делаете, а не базу данных разрабатываете?

надеюсь что нет, хотя статьи по распределённым субд мне уже начали попадаться