I'm working on a movie-reviewing api-project using Domain-Driven Design (DDD) principles. I wonder how to differ between the core and orchestration logic. I have a use-case called "remove-from-watchlist" which should add a movie to the current users watchlist. When a user runs the use-case "watched-movie" meaning it marks a movie as being watched, I also need to remove the movie from the users watchlist. Now, should I reuse the use-case "remove-movie-from-watchlist" from within my use-case "watched-movie" when folmowing DDD?
I see a problem with this, because in my opinion a "use-case" is the orchestration of one specific "story". Suppose for example that, when a user removes a movie from the watchlist for the first time, we want to send an email to them. Now, if we were to reuse this use-case in "watched-movie-use-case", the user would get an email that doesn't really fit what they were doing. Should I instead break out the logic of removing a movie from the watchlist into a service, which could then be reused, from both use-cases? This service would essentially be a core-service, not sending the email, just simply removing the movie from the watchlist. Also, in DDD, am I right in calling this "story" for a use-case? I have seen some resources online instead using the word use-case to describe a service