In this talk, I want to formulate a number of arguments against following the "Fat Models" and rival approaches to organising Business Logic code in a Django project codebase and ultimately suggest a better solution and outline possible advantages and disadvantages of each approach.

Attendees should get a clear image of all the possible problems stemming from following the "Fat Models" approach to organising Business Logic in a Django project and be able to evaluate how alternative approaches fit their needs.

In this talk, I want to formulate a number of arguments against following the "Fat Models" and rival approaches to organising Business Logic code in a Django project codebase and ultimately suggest a better solution and outline possible advantages and disadvantages of each approach. The discussed approaches include: 1. Organising BL code as Models' methods. 2. Dispersing BL code between a number of Views, Forms, and/or Serializers. 3. Defining a completely separate Services layer. 4. Organising BL code as QuerySets'/Managers' methods. An example for each approach is given by a way of a real-world example and each approach is evaluated according to the following criteria: - Code repetition (violation of the DRY principle); - code testability; - code readability. Finally, a discussion of new challenges stemming from the proposed Approach no 4 - especially concerning business rules validation and integration with external APIs - is presented.