Separação de lógica de negócios e acesso a dados no django

| | | | | | | | | | | | | | | | | |

Estou escrevendo um projeto em Django e vejo que 80% do código está no arquivo models.py. Esse código é confuso e, depois de um certo tempo, deixo de entender o que realmente está acontecendo.

Aqui está o que me incomoda:

  1. Acho feio que meu modelo nível (que deveria ser responsável apenas pelo trabalho com dados de um banco de dados) também está enviando e-mail, andando na API para outros serviços, etc.
  2. Além disso, acho inaceitável colocar lógica de negócios em a vista, pois assim fica difícil de controlar. Por exemplo, na minha aplicação existem pelo menos três maneiras de criar novas instâncias de User, mas tecnicamente deveria criá-las uniformemente.
  3. Nem sempre percebo quando os métodos e propriedades dos meus modelos tornam-se não determinísticas e quando desenvolvem efeitos colaterais.

Aqui está um exemplo simples. No início, o modelo User era assim:

class User(db.Models): def get_present_name(self): return self.name ou "Anonymous" def activate(self): self.status = "activated" self.save() 

Com o tempo, transformou-se nisso:

class User(db .Models): def get_present_name(self): # propriedade se tornou não determinística em termos de banco de dados # dados são retirados de outro serviço por api return remote_api.request_user_name(self.uid) ou "Anonymous" def activate(self): # método agora tem um efeito colateral (enviar mensagem para o usuário) self.status = "ativado" self.save() send_mail("Sua conta está ativada!", "‚Ķ", [self.email]) 

O que eu quero é separar as entidades no meu código:

  1. Entidades do meu banco de dados, nível de persistência: Quais dados meu aplicativo mantém?
  2. Entidades do meu aplicativo, nível de lógica de negócios: o que meu aplicativo faz?

Quais são as boas práticas para implementar tal n abordagem que pode ser aplicada no Django?