大型(Ish) django应用程序架构

Question

如何正确地构造一个更大的django网站，例如保持可测试性和可维护性？

本着最好的django精神(我希望)，我们一开始就不太关心网站不同部分之间的脱钩。我们确实将其划分为不同的应用程序，但这些应用程序通过常用的模型类和直接方法调用而直接相互依赖。

这件事越来越纠结了。例如，我们的一个操作/服务如下所示：

def do_apply_for_flat(user, flat, bid_amount):
    assert can_apply(user, flat)
    application = Application.objects.create(
        user=user, flat=flat, amount=bid_amount,
        status=Application.STATUS_ACTIVE)

    events.logger.application_added(application)
    mails.send_applicant_application_added(application)
    mails.send_lessor_application_received(application)
    return application

该功能不仅执行实际的业务流程，不，它还处理事件记录和发送邮件给涉及的用户。我不认为这种方法本质上有什么问题。然而，对代码进行适当的推理甚至测试应用程序变得越来越困难，因为在智能和编程上分离部分变得越来越困难。

所以，我的问题是，大男孩是如何构造他们的应用程序的：

1. 应用程序的不同部分可以单独测试。
2. 通过只启用特定测试真正需要的部分，测试将保持快速。
3. 减少代码耦合

我对这个问题的看法是引入一个集中的信号中心(只是一个python文件中的一组django信号)，单个django应用程序可能会发布或订阅它。上面的示例函数将发布一个application_added事件，邮件和事件应用程序将监听该事件。然后，为了进行有效的测试，我会断开我不需要的部件。这也大大增加了解耦，因为服务根本不需要知道如何发送邮件。

但是，我不确定，因此我对这些问题的公认做法很感兴趣。

Answer 1

将应用程序的某些部分转移到不同的微服务。这将使你的应用程序的某些部分专注于做一两件正确的事情(例如，事件记录、电子邮件)。代码耦合也减少了，站点的不同部分也可以单独测试。

微服务体系结构风格包括将单个应用程序开发为一组较小的服务，这些服务通常通过API进行通信。

您可能需要使用一个更小的框架，如烧瓶。

资源：

有关微服务的更多信息，请点击此处：

http://martinfowler.com/articles/microservices.html

http://aurelavramescu.blogspot.com/2014/06/user-microservice-python-way.html

Answer 2

对于测试，您应该模拟您的依赖项。例如，在视图的单元测试期间，应该对日志和邮件组件进行模拟。我通常使用python-模拟，这允许独立于日志记录和邮件组件测试视图，反之亦然。只需断言您的视图正在调用正确的服务调用，并模拟服务调用的返回值/副作用。

在进行测试时，还应该避免接触数据库。相反，尝试尽可能多地在内存对象中使用，而不是Application.objects.create()，将save()推迟到调用方，这样您就可以测试服务，而不必在数据库中实际使用该应用程序。或者，修补save()方法，这样它就不会实际保存，但这要繁琐得多。

Answer 3

首先，试着把你的大任务分解成更小的班级。将它们与通常的方法调用或Django信号连接。

如果您认为子任务是足够独立的，您可以将它们作为几个Django应用程序在同一个项目中实现。请参阅Django教程，它描述了应用程序和项目之间的关系。