и single level of abstraction не соблюдается

Подскажите что мне делать в этой стуации.

Есть доменный сервис, который получает на вход агрегат и возвращает другой. Для создания агрегата нужен id, который я получаю из репозитория.

Вопрос, что делать?

1) Инжектить репозиторий в доменный сервис и получать id из сервиса?
2) Или делать провайдер id, который я буду передавать при вызове метода сервиса?
3) Или вообще получать id до вызова сервиса и передавать уже готовый id?

Вот почему я сомневаюсь

1) Если инжектить, то в юнит тестах придется стабить
2) Если делайть провайдер для метода, то выглдяит как лишняя абстракция
3) Если получать id до обращениея к сервису, то это потенциально лишнее обращение к бд

Подскажите бест практис

> фабричный метод всегда в отдельной фабрике(конструктор классов в домене публичный, перегруженный)
А может большой конструктор показывает на плозой кохижн и плохую декомпозицию?

перегруженный в плане method overloading)

работать через guid, генерить его на сервере приложений, а не в БД  в этом случае.

не пойдет, у меня уже id

тогда вариант 2, провайдер

так и сделал, спасибо

Hello everybody!!!
We are calling for startup founders on MVP-ready stage to pitch investors, angels and community-at-large and secure smart feedback and new tools and contacts.Join our networking and pitch event at Imaguru Startup HUB in Vilnius.
The event will be streamed online at Imaguru Facebook page, also you can come and join us in Imaguru Vilnius.

December 3 at 18:30.

We invite startups at the product and MVP stages to the Friday Pitch event, which will bring together investors, startup founders, angels and experts. Imaguru will select the 3 best startups that will pitch the participants of the event - 3 minutes, in English . After the startup pitches, networking awaits the participants.

📌Link to sign up https://airtable.com/shrmCr7jIssrW1j1W

Спит как обычно )

Наелся и спит

+

Подскажите, правильно ли я понимаю, что паттерн репозитория не предполагает метода update?

думаю так и есть. Это ж не работа с БД напрямую, это абстракция. Есть просто коллекция объектов предметной области, достаём объект, меняем. Изменение стейта будет при вызове методов объекта.
Когда есть апдейт в репозитории - это торчит деталь реализации не относящаяся к предметной области (сразу вопросики возникают - а что, я вот стейт объекта поменял, а он не поменялся? Надо ещё какой-то апдейт делать?)

Вот отсюда и вытекает мое недопонимание. На объекте-сущности вызвал метод, который изменил его состояние. Например:

orders = OrderRepository(...)
order = orders.findById(123)
order.markFinished()

Внутри order изменилась дата. Как репозиторий должен узнать об изменениях?

ну есть же всякие UOW-ы в ORM. Там будет метод, который позволит сбросить изменения в бд, но к репозиторию это по идее отношения не имеет

ну или сделать репозитрию метод save