это ж создает зависимость, coupling для тендера и ордера. Не проще ли иметь бизнес обьект, обьединяющий эти 2 обьекта, типа CompletedTender? Это будет класс на уровне бизнес логики, ViewModel

Тендер и должен зависеть от ордера

Так это зависимость на уровне бизнес логики, или данных? Если данных, то у нас будет 1 TenderAndOrderRepo, и все
Если ордер существует сам по себе, а тендер сам по себе, но юзер может их обьединять - это зависимость на уровне бизнес логики

Ааа, вот оно как. Понял, спасибо

а такой вариант не будет менее костыльным?

FeatureState

NormalState(List<String>) : FeatureState

DialogState(String, FeatureState) : FeatureState

продолжаем-с серию вопросов про ТЕА-подобные архитектуры

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

Типа, из очередного апдейта постить эффект в виде таймера, чтобы он сработал через N минут?

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

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

в этом случае минус в том, что у меня два таймера - eachSecondTimer и userUpdateTimer, что странно выглядит, но не кажется смертельным

Добрый день, подскажите, если я делаю относительно небольшое приложение, то такие вещи как: app, domain, data можно лучше будет создать просто отдельными пакетами, или лучше это сделать модулями отдельными?

можно начать с того, что вообще не создавать их)

Почему?

а зачем оно нужно?

Я только clean архитектуру осваиваю, вот решил попробовать сделать все красиво

если это учебный проект, делай по всем правилам

А что вы писали выше на счёт не создавать их вообще? Не совсем понял

Если не работал с модулями до этого то лучше делай все в одном отдельными пакетами
для небольшого приложения модули это скорее лишнее усложнение

Я вот тоже так думаю

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

Ну если по фасту то да конечно