在 Django 中，建议的软件架构是将所有业务逻辑和数据访问放在模型中。
但是，有同事建议数据访问层应该与业务逻辑（业务服务层）分开。他们的理由是，如果使用不同的数据源，数据访问层可以隔离更改。他们还说，存在可以在多个模型中的业务逻辑。
但是，当我开始使用单独的数据访问层和业务逻辑层进行编码时，数据访问层很简单（基本上是定义 db 模式的模型代码）并且似乎没有增加太多价值。
将数据访问从 django 模型中分离出来真的有价值吗，还是 django 已经通过其 ORM 提供了足够的数据访问层？
我正在寻找已经实现了大量 django 应用程序的开发人员，并了解他们的意见。这适用于中小型 Web 应用程序。
经过三年的 Django 开发，我学到了以下内容。
ORM 是访问层。不需要更多了。
50% 的业务逻辑都在模型中。其中一些在表格中重复或放大。
20% 的业务逻辑在 Forms 中。例如，所有数据验证都在表单中。在某些情况下，表格会将一般领域（模型允许）缩小到特定于问题、业务或行业的某个子集。
20% 的业务逻辑在应用程序的其他模块中结束。这些模块位于模型和表单之上，但位于视图函数、RESTful Web 服务和命令行应用程序之下。
10% 的业务逻辑在使用管理命令界面的命令行应用程序中结束。这是文件加载、提取和随机批量更改。
视图函数和 RESTful Web 服务几乎什么都不做，这一点非常重要。他们尽可能多地使用模型、表格和其他模块。视图函数和 RESTful Web 服务仅限于处理变幻莫测的 HTTP 和各种数据格式（JSON、HTML、XML、YAML 等）。
试图发明另一个访问层是一项零价值的练习。
答案取决于您的应用程序的要求。
对于将始终使用关系数据库并可以与特定 ORM 耦合的应用程序，您不需要分离数据访问和模型。Django ORM 基于活动记录设计模式，假设数据访问和模型是在一起的。优点是简单，缺点是灵活性较低。
仅当开发人员想要完全解耦数据访问层和业务逻辑时，才需要分离数据访问和模型。您可以使用数据映射器设计模式来做到这一点。一些 ORM 支持这种设计模式，例如 SQLAlchemy。Pro 更灵活，con 更复杂。
我推荐 Martin Fowler 撰写的《企业应用程序架构模式》一书以了解更多详细信息。