I'm having hard time finding a place to implement logic.
Suppose there is a repository of bookmarks. The repository can be observed via Flow. Resulting bookmark content can be influenced by events like user logout, bookmarked item getting removed which would alter the resulting set of bookmarks.
I have two places in mind where I can put the logic of reacting to such events:
- From within the use case, say GetBookmarks: I could construct resulting flow such that it would not only proxy repository get call but also would observe logout events and run update repository actions in the very same flow.
- From a state holder, say actor or viewmodel, that would accept dumb implementation of GetBookmarks (that does nothing but proxy repo's get method call) and a source of logout events, ultimately handling such logout events inside actor's execution process.
It might get cumbersome to go with the first option but UseCase seems to be a good candidate for business logic like reacting to other business events. On the other hand, with option 2, state holder's implementation would be easier but would place more business logic inside the state holder.
Is there a distinction or principle I could apply to make final decision?