3

So in my python django application the architecture is structured such that it is separated into different apps. One app for users, one for finance, etc.

Each app has the following base structure:

app_name
    models
    services
    tests

I am developing a new feature to support promo codes. Promo codes will allow the user to receive a discount for their upcoming bill(s). So I created a PromoCodeModel and a PromoCodeService. Inside the service I need to check if a user is eligible to redeem this code. It seems like this logic could get fairly complicated and I was hoping to encapsulate the eligibility checks into its own class -- something like PromoCodeEligibility(user, promo_code).

I was wondering -- where would this belong? Should I create a new PromoCodeEligibilityService? Or should I create a new folder called domain and make this a domain object? I could also move this logic into the model itself but having really fat models seems like more of an anti-pattern to me. Thoughts?

Atul Bhatia
  • 1,633
  • 5
  • 25
  • 50

1 Answers1

0

I could also move this logic into the model itself but having really fat models seems like more of an anti-pattern to me. Thoughts?

Actually this is the preferred way in Django. You can read more about this here and here and here.

PS. I'm pretty sure there were a few sentences about the topic inside django docs, but can't find it.

Community
  • 1
  • 1
Todor
  • 15,307
  • 5
  • 55
  • 62
  • Let us assume we aren't using django though -- where would it go then? – Atul Bhatia Apr 04 '15 at 05:26
  • Also those article are simply advocating not to put the logic in the views, etc. I am basically trying to split up "fat models" into separate classes. meaning it will still live at the domain layer. – Atul Bhatia Apr 04 '15 at 05:35