I agree with you. It is a bit weird that a serializer can interact with the database but what it basically does: hides the database interaction.
* Write the `create()` and/or `update()` methods explicitly on the serializer class.
* Push logic into the model and model manager where possible and only have the serializer `.save()` as a thin layer on top of that.
That way a serializer class still has all the behavior it needs to map both ways between persisted objects and their corresponding native python representations, but you still have a well separated model API.
The "deserializer"'s job is to perform validation and type coercion of incoming requests. It returns a "native" dictionary, which the application code then saves to ORM.
The "serializer" is basically a presentation layer. It calls out to other nested serializers [this is awesome!], and it throws in convenience-fields that make the API response easier to consume.
This pattern makes it a little bit less "magical", and it's easier to distinguish between the API's "incoming" behavior and its "outgoing" behavior.