Oddzielenie logiki biznesowej i dostępu do danych w django

Piszę projekt w Django i widzę, że 80% kodu znajduje się w plikumodels.py. Ten kod jest mylący i po pewnym czasie przestaję rozumieć, co się naprawdę dzieje.

Oto, co mnie niepokoi:

Uważam za brzydkie, że mój poziom modelu (który miał być odpowiedzialny tylko za pracę z danymi z bazy danych) to także wysyłanie wiadomości e-mail, chodzenie po API do innych usług itp.Uważam również za niedopuszczalne umieszczanie logiki biznesowej w widoku, ponieważ w ten sposób trudno jest kontrolować. Na przykład w mojej aplikacji istnieją co najmniej trzy sposoby tworzenia nowych instancjiUser, ale technicznie powinien je tworzyć jednolicie.Nie zawsze zauważam, kiedy metody i właściwości moich modeli stają się niedeterministyczne i kiedy rozwijają się efekty uboczne.

Oto prosty przykład. Na początkuUser model był taki:

class User(db.Models):

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

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

Z biegiem czasu stało się to:

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])

Chcę oddzielić elementy w moim kodzie:

Podmioty mojej bazy danych, poziom bazy danych: co zawiera moją aplikację?Podmioty mojej aplikacji, poziom logiki biznesowej: Co może zrobić moja aplikacja?

Jakie są dobre praktyki wdrażania takiego podejścia, które można zastosować w Django?

questionAnswers(9)

yourAnswerToTheQuestion