原文地址： Django 1.11.18.dev20181205205104 documentation
设计哲学
这个文档阐释了一些django开发者使用在django中的基本哲学。它的目标是解释过去和指导未来。
松耦合
django技术栈的一个基本目标就是”松耦合、高内聚“。框架的各个层在不必要的情况下，不必知道其他各层。
例如，template层不知道web requests，数据库层不知道数据展示层，视图层不在意用户使用哪个template。
虽然django带来了全栈解决方案的便捷，栈的各个层都尽量独立于其他的层。
更少的代码
django的应用应该使用尽可能少的代码，他们那应该是缺少样板。
Django应该充分使用python的动态能力，比如自省。
快速开发
21世纪框架的特点是让冗长复杂的开发变得快捷。django允许快速进行web开发。
DRY，不要重复造轮子
每个截然不同的概念或者数据应该存放在一个地方，而且只有这个地方。
冗余是不好的，标准化是好的。
作为框架，合理的情形就是从尽可能少的内容推断出尽可能多的内容。
显示比隐式更好
这是在PEP20中列出的核心python原则，这意味着django不应该做太多”魔法方法“。至少有一些很耗的理由说明”魔法方法“不应该出现。如果”魔法方法“创造了一大堆方便的，并且其他方法难以实现的方法时，这才是”魔法方法“唯一值得使用的地方，并且它不能用一种让尝试学历如何使用这些特性的开发者感到困惑的方式。
一致性
框架应该从所有层面进行考虑。这些考虑包括任何事情，从低级的python代码风格到高级的使用django的经验。
Models
显示比隐式更好
字段不应该假定仅仅由它的名字来确定，这需要太多操作系统的知识并且容易出错。相反，在某些情况下，行为应该基于关键字参数，比如字段的类型。
包含所有的相关域的逻辑
模型应该将一个”对象“的所有属性封装起来，遵循Martin Fowler的Active Record设计模式。
这就是为什么数据用模型来表示，并且它被定义在模型类中(比如人类可读的名字，默认排序这样的选项，等等)。所有的信息需要知道被存储在某一个模型中。
Database API
以下是database API的核心目标：
高效SQL
应该以尽可能少的时间来执行SQL，并且应该在内部优化SQL的声明。
这就是为什么开发者需要显示的调用save()，而不是框架在场景背后默默的进行保存操作。
这也是为什么select_related()方法存在的原因。这是一种非强制执行的，一般情况下选择所有相关对象的助推器。
简洁又强大的语法
数据库API应该允许丰富，在尽可能简短的语句中富有表现力。不应该依赖导入其他模块或者辅助对象。
联结应该在必要的时候，在使用场景背后被自动执行。
系统层面，每个对象可以被关联对象访问。
选择原生SQL更简单，如果我们需要的话
数据库API应该意识到它只是捷径，并非必须。框架应该让自定义SQL更容易--完整的声明，或仅仅通过调用API自定义WHERE从句。
URL 设计
松耦合
django应用中的路由不应该耦合到python代码上。将路由绑定到python函数名是一种不好而且丑陋的做法。
沿着这些做法，django路由系统允许相同的应用在不同的上下文中不同。例如，一个站点把要存储的内容放在 /stories/ 中，又或者存放在 /news/中。
无限的灵活性
路由应该尽可能的灵活，任何能想象到的路由设计都应如此。
鼓励最佳实践
框架应该让它对开发者而言变得简单来设计漂亮的路由。
网页中的文件的扩展名应该被隐藏。
不可更改的路由
从技术上讲，foo.com/bar 和 foo.com/bar/ 是两个不同的路由，并且搜索引擎(和其他web分析工具)会把它们当做两个不同的页面。django努力的标准化路由，目的是让搜索引擎不再困惑。
这就是APPEND_SLASH设置背后的推论。
模板系统
分离逻辑
我们把模板系统看做一个工具，一个控制页面展示和页面展示相关逻辑的工具。
模板系统不应该支持超过它基本目标的功能。
阻止冗余
大多数动态网站使用一些常见的网站设计--通用的header，footer，navigation bar，等等。django模板系统应该让这些元素存储在同一个地方更简单，从而去除重复的代码。
这就是template inheritance背后的设计哲学。
从HTML中解耦
模板系统不应该设计为仅仅展示HTML。它应该在生成基于文字的格式化方面同样优秀，或者仅仅是文字。
XML不应该用于模板语言
在编辑末班时，使用XML引擎来解析模板引入了一个全新的错误--并且引发了一个在模板处理中不可接受的开销。
假定设计者的能力
模板系统不应该被设计，目的是模板必须被很好的展示在所见即所得的编辑器中，比如Dreamweaver。这是严重的
网友评论