模型定义中的业务逻辑还是单独的服务层？

Question

我想知道哪个是使用mongonegine python的模型（ORM）的正确方法。

我有一个直接映射到 mongodb json 文档的优惠券类。

class Coupon(Document):
    __collection__ = 'coupon'

    coupon = StringField()
    points = IntField()

    @property
    def increment(self):
        self.points += 1

    @property
    def decrement(self):
        self.points += 1

我发现上面的问题是，我们将行为绑定到数据库访问层，我认为这是不正确的做事方式(我可能完全错了）。

另一种方式 （我认为更有意义） 将业务逻辑委托给通常称为 服务 层的其他层： p>

models.py

class Coupon(Document):
    __collection__ = 'coupon'

    coupon = StringField()
    points = IntField()

services.py

from models import Coupon

def increment_points(c_id):
   c_id.points+=1

我想知道哪种是正确的做事方式（假设我们有很多模型）。

问题：我们应该将行为绑定到模型还是将服务层用于业务逻辑？

注意：我添加了标签python，因为我看到很多人在他们的代码库中将行为和业务逻辑绑定到数据库访问层。在任何关于服务的教程中很少听说python web 框架。但它在 Java 和 PHP 中很常见。

Answer 1

您可以在 DDD（领域驱动设计）方法中找到很好的启发式方法来构建项目职责。 项目通常具有领域逻辑（一些业务规则和操作）和应用程序逻辑（业务流程的编排，如执行领域对象方法、数据库访问、外部服务请求等）。领域逻辑应该在实体和领域服务中实现，而应用逻辑应该在应用服务中实现。

你说行为不应该绑定到数据库访问层。您是对的，但解决方案不是将业务逻辑移动到服务层（应用层），而是将域模型和持久模型分开（并将域逻辑保留在域模型中）。如何在python中做到这一点？您可以在这里找到解决方案：

• Persist POJOs in Python using a DDD approach
• https://jorzel.hashnode.dev/persistence-and-domain-model-separation-using-sqlalchemy-orm