One Api - One Service

[HomaDev]

Hi, again @RadoRado 👋 hope you are doing well! I have been working on my project for a while now since I decided to move it to services architecture, and now I've found It difficult to follow one model - one service "rule" because some of my APIs need more than one model data. I'm curious if you and your team were trying to use one API - one service approach if it worked for you or not, and why if not. Anyway, thanks again for such a nice styleguide, it helped me improve the quality of my code a lot

[RadoRado]

@HomaDev Hello :wave:

One model <-> One service is a not good rule to follow, because this simply recreates the idea with the generic APIs, thus, removing control from you.

It'd be really helpful for us, if you can add few more paragraphs about this & if the Django Styleguide, somehow, conveyed this particular message. Perhaps our examples can be improved.

The general idea of the service layer is to model closer to your domain, rather than closer do your relation database structure.

When the projects are small enough and simple enough, usually the domain & the relation database structure move closer together.

Of course, this is not always the case.

That's why, we highly recommend grouping domain / business logic together, in a meaningful way, in the service layer.

This often means dealing with 1, 2, 5 or even more models, at the same time, in the same service.

Hopefully this can clarify things a bit.

Cheers!

[HomaDev]

@HomaDev Hello 👋

One model <-> One service is a not good rule to follow, because this simply recreates the idea with the generic APIs, thus, removing control from you.

It'd be really helpful for us, if you can add few more paragraphs about this & if the Django Styleguide, somehow, conveyed this particular message. Perhaps our examples can be improved.

The general idea of the service layer is to model closer to your domain, rather than closer do your relation database structure.

When the projects are small enough and simple enough, usually the domain & the relation database structure move closer together.

Of course, this is not always the case.

That's why, we highly recommend grouping domain / business logic together, in a meaningful way, in the service layer.

This often means dealing with 1, 2, 5 or even more models, at the same time, in the same service.

Hopefully this can clarify things a bit.

Cheers!

Hi again. Now reviewing the guideline's section with services, I can see that you were not telling about one model - one service, and I don't know why I was convinced in other.

For now, I decided to cut services in two parts 1- for generic services that can be reused, and 2 - api-specific class based services that follow one api - one service rule that won't be reused. I think this way it will be much more clear to understand where the logic of an api lives, and will help not to make a large web where every service calls every other service. Of course not sure about this approach, and I think I'm missing something like always, but I will try it, and maybe it will make me closer to design I'm looking for.