Django业务逻辑放置：模型内还是服务层？哪种更符合最佳实践？

两种方案的核心区别 #

1. 模型内方法方案 #

这种方案属于领域模型模式，把与Property实体强相关的行为直接封装在模型内部：

def mark_as_active(self):
    self.is_draft = False
    self.is_paused = False
    self.published_at = timezone.now()
    # 其他仅涉及Property自身的操作
    self.save()

• 核心特点：紧密绑定实体，符合"对象=数据+行为"的面向对象设计思想，调用时直接通过实例调用（property_obj.mark_as_active()），代码简洁直观。
• 局限性：如果逻辑需要跨多个模型协作（比如关联PropertyPlan），会导致模型职责膨胀，打破单一职责原则，后续维护难度上升。

2. 服务层方法方案 #

这种方案属于服务层模式，把跨模型、复杂的业务逻辑抽离到独立的服务模块中：

def mark_property_as_active(property_id, property_plan_id):
    property = Property.objects.get(pk=property_id)
    now = timezone.now()
    
    property.is_draft = False
    property.is_paused = False
    property.published_at = now

    # 关联PropertyPlan的操作
    plan = PropertyPlan.objects.get(pk=property_plan_id)
    property.plan_id = plan.pk
    property.plan_expires_at = now + datetime(days=plan.timestamp_days)

    property.save()

• 核心特点：专注于业务流程的协调，模型仅负责自身的数据持久化和简单属性操作，避免模型承担额外的跨模型逻辑。
• 局限性：调用时需要先查询实例，代码偏向过程式，但逻辑集中，便于统一维护和测试复杂业务场景。

最佳实践选择 #

没有绝对的优劣，需根据业务逻辑的复杂度选择：

• 简单单模型逻辑：如果只是修改Property自身的状态（比如仅设置is_draft、is_paused），优先用模型内方法，符合封装原则，代码更优雅。
• 跨模型/复杂逻辑：如果逻辑涉及多个模型交互（比如关联PropertyPlan设置套餐），更适合放在服务层，保持模型的单一职责，后续扩展新逻辑（比如添加操作日志、发送通知）时，只需修改服务层代码，无需改动模型。

内容的提问来源于stack exchange，提问作者rediz