I am writing my first bigger API, which is based on three entities (cinema, movies, movie properties). I try divide my methods like below:

1. MovieServiceImpl:

   saveMovie(), findMovieByID(), deleteMovieByID, 
   showMovieWithCinemasList(), enrolledPropertyToMovie()
   

2. CinemaServiceImpl

   saveCinema(), enrolledMovieToCinema(), showCinemasWithMovieList()
   

3. PropertyServiceImpl

   saveProperty(), findPropertyByID()
   

4. ReservationServiceImpl

   showFreePlaceOnMovie(), showDateChosenMovie(), showRepertoire(), 
   showCinemasWithMoviesLisT(), multiplePlaceReservation()
   

Question

1. Whether it is compatible with the Single Responsibility Principle (SRP).

2. And it is a good practice to divide it into smaller Services if not what should I do?

CodePudding user response：

Your question is a bit unclear.

Single Responsibility Principle mandates single responsibility for a single structural unit of work (class, module, interface, method, whateverunityourlanguage has), i.e. one entity/unit responsible(/solving) one particular problem.

For instance, if you have a method:

Person getPersonById(int id) {...}

you should never implement validation or authentication logic in it; instead, you should delegate that responsibility to another layer/object.

This has almost nothing to do with "can I have several types in the application?", and to be honest, I can't think of any application (unless it's a really small console app), which doesn't have several structural units (entities, like class, interface, etc.) in itself.

Your example doesn't show anything about SRP, but rather solely demonstrates, that you have different types for different business domain models, and that's much, much better way of designing application/types, in contrast to having one messy class for working with different domain objects/logic.

If, however, you violate SRP in the methods of those classes, that's another story, and we can't address it here, as you don't show implementations.

I still think, that your question was more about having different types, instead of incorporating all of them in one (a horrible idea!), and in your example, Movie, Cinema and Property are three different domain entities, which is - again - good.

Regarding:

And it is a good practice to divide it into smaller Services if not what should I do?

It's unclear what do you mean in "smaller services" and what is your question about. It seems to me, that you're working with nTier/Layered architecture, and only thing I can tell you, that - yes, it's good to separate responsibility layers.

CodePudding user response：

Blockquote I still think, that your question was more about having different types, instead of incorporating all of them in one (a horrible idea!), and in your example, Movie, Cinema and Property are three different domain entities, which is - again - good.

Yes my question was just about it!

And by the way, you made me realize that it should separate the validations to other methods so that my code becomes better and meets the SRP as well.

Thanks for the answer, although it seemed logical to me, I needed confirmation from someone experienced. Thank you very much!!!