I have an endpoint that should create a book, and if it is the clients first created book it should send an email like "Congratulations to your first book". Following Clean Architecture I thought I would create a CreateBookUseCase that both creates the book and sends the email. But I realised that does not really make sense, because now the use-case does more than it should, and also I dont want to send this email if another use-case creates a book as a side-effect, I only want to send the email if the action of creating a book has been sent from the client in this case. So how would I in Clean Architecture differ between a core use-case such as CreateBookUseCase that could potentially be reused, and a use-case that is orchestrated from multiple use-cases?
I was thinking about ways to differ between these two. Maybe call the orchestrated one CreateBookWorkflowUseCase or maybe have another type of use-cases I call Facades, which essentially is the outer use-cases used by other parts like the client, either through an api or something like a cli. So it could be CreateBookFacade. I also thought about something like HandleCreateBookActionUseCase to make it clear that the use-case is not made to "create a book", rather it handles when someone from outside our system executes the action of wanting to "create a book". I like the last alternative, but do not really know if it follows best-practices and is scalable.