Separación de lógica de negocio y acceso a datos en django

Estoy escribiendo un proyecto en Django y veo que el 80% del código está en el archivo models.py. Este código es confuso y, después de un cierto tiempo, dejo de entender lo que realmente está sucediendo.

Esto es lo que me molesta:

1. Me parece feo que mi nivel de modelo (que se suponía que era responsable solo del trabajo con datos de una base de datos) es también enviar correo electrónico, caminar en API a otros servicios, etc.
2. Además, me parece inaceptable colocar la lógica de negocios en la vista, porque de esta manera se vuelve difícil de controlar. Por ejemplo, en mi aplicación hay al menos tres formas de crear nuevos instancias de User, pero técnicamente debería crearlas uniformemente.
3. No siempre me doy cuenta cuando los métodos y las propiedades de mis modelos se vuelven no deterministas y cuando se desarrollan efectos secundarios.

He aquí un ejemplo sencillo. Al principio, el modelo User era así:

class User(db.Models):

    def get_present_name(self):
        return self.name or 'Anonymous'

    def activate(self):
        self.status = 'activated'
        self.save()

Con el tiempo, se convirtió en esto:

class User(db.Models):

    def get_present_name(self): 
        # property became non-deterministic in terms of database
        # data is taken from another service by api
        return remote_api.request_user_name(self.uid) or 'Anonymous' 

    def activate(self):
        # method now has a side effect (send message to user)
        self.status = 'activated'
        self.save()
        send_mail('Your account is activated!', '…', [self.email])

Lo que quiero es separar entidades en mi código:

1. Entidades de mi base de datos, nivel de base de datos: ¿Qué contiene mi aplicación?
2. Entidades de mi aplicación, nivel de lógica de negocio: ¿Qué puede hacer mi aplicación?

¿Cuáles son las buenas prácticas para implementar tal enfoque que se puede aplicar en Django?