I don’t believe it does. Taking care of all the steps involved in account creation (in the example I used) can be considered one thing, it’s an account creation.
Plus, CA advocates against UC calling each other; they are vertical “slices” in your application layers and therefore should be isolated to avoid crossing boundaries.
This point in particular seems open to interpretation though and it’s a frequent topic on Stack Overflow.
DDD answers the issue of crossing boundaries with the notion of bouded contexts. You can read more about that on Martin Fowler’s blog.
At the end of the day, I believe you have the right, as an architect, to choose the trade offs that suits you the best 👍
As you mention the collaboration between interactors, what's your appoach in this cases? How do you share behavior between interactors without having them call each other?
I don’t believe it does. Taking care of all the steps involved in account creation (in the example I used) can be considered one thing, it’s an account creation.
Plus, CA advocates against UC calling each other; they are vertical “slices” in your application layers and therefore should be isolated to avoid crossing boundaries.
This point in particular seems open to interpretation though and it’s a frequent topic on Stack Overflow.
DDD answers the issue of crossing boundaries with the notion of bouded contexts. You can read more about that on Martin Fowler’s blog.
At the end of the day, I believe you have the right, as an architect, to choose the trade offs that suits you the best 👍
I'm on board with @bdelespierre here. If you think from the perspective of reasons to change the
CreateUserInteractoris not violating SRP at all.As you mention the collaboration between interactors, what's your appoach in this cases? How do you share behavior between interactors without having them call each other?
Behavior shared amongst use cases should go into shared services if and only if it's not incidental dupplication.