Łukasz Haze

One clarification: there's no need for making session model/service/whatever user-model-aware. Two reasons: - There are lots of applications where having a session instance doesn't imply having a user model instance...

Example of problems mentioned in (2): > ### Exceptions are not exceptional > Let’s look at another example, a typical code to access remote HTTP API: > ```python > def...

What can be done: - A request model may be constructed by a factory just as any other input for the interactor. Don't just pretend it is brought by some...

Ok, let's take [Sobolev's example](https://github.com/pcah/python-clean-architecture/issues/67#issuecomment-560479076) to formulate expectations about Interactor (aka Use Case): - Interactor orchestrates components for the application's logic to consume - it combines a sequence of operations...

What can be done (cont'd): - The Interactor (as a design pattern) should not have input data supplied by the call arguments. This becomes obvious when you look at examples...

### Interactor as process orchestrator vs. immutability #### Process Orchestrator You might think that `Interactor`, as an orchestrator of all the fragments of process' logic, might be a container for...

Ok, let's keep it simple. Imagine we have a function defining interaction logic. We want to make it: - callable with nothing but a reference to the `Interactor` instance (which...

An interaction logic function defined outside the interactor. #### Example 2 (no composition, external function) ```python # pure_domain_logic.py @success @inject def add_member( interactor: Interactor, team_repo: Repository = Inject(qualifier=Team), **kwargs) ->...

The reason behind all this stuff: [Railway-Oriented Programming](https://fsharpforfunandprofit.com/rop/)

Let's look into a somewhat common use-case: an entity has a list of other instances as its components. For example, let's take an `Invoice` entity with a list of `InvoiceFields`....