什么是app
app是django项目的基本组织单元，其本身是标准的python package，只是其中还会有符合django约定的py文件，如models.py等。
如何划分app
从网上看到的各种说法来看，划分app的建议是功能逻辑的“内聚性”。将独立的具体功能放置在一个app中，于是app既划分了功能需求也是在多个django项目之间进行代码重用的手段。
一个简要的指标是，当models.py中的model超过5个（10个）后就可以考虑拆分了。
那问题呢
app划分困难
- 首先，项目中很难有一个彻底独立的模块，功能需求间总会有相关联的内容。这个时候分或是不分就成了问题。
- 其次，随着项目的进行需求变化功能增加是少不了的。也许开始时app划分的很不错，但随着代码不断被添加，app逻辑上的内聚就会出现些问题，总会混杂进新代码。
app拆分困难
- python代码重构ide支持较差，动态语言的硬伤。没有ide帮助下进行重构是相当有风险的，且这么吃力不讨好的事情最好避免去做。
数据库同步易出问题
- syncdb/south并不一定能在此种场景下正常工作，随便出点什么问题就够头疼了。
不用app行不行
当然可以，将所有逻辑放到一个app中就可以了。这里还是想吐槽下django关于models.py、views.py、tests.py的约定，
单一文件真能满足大项目的需求吗？
将多个model放在一个models.py中很容易就会让这代码膨胀，这里还是更偏好java的形式，一个class一个类，简单明了。
有什么好处
- 数据库同步简便。south schemamigration/migrate只需要操作一个app即可，容易保证一致性。
- 层次依然清晰。在一个app中同样可以将代码逻辑整理清楚，python package就已经可以进行层次化设计。
有什么坏处
- 不django，要是放到github上去没准就会被bs..
结论
个人结论就是通过package组织代码，避免创建使用多个app，减少数据库同步问题。如若代码需要进行项目间的重用，可以随时提前模块化的package。
以上观点来自于目前的项目经验，也许之后会认为app才是正道也不一定。