在上一篇博文中，描述了一些django项目结构的实践，但实际上还有很多改进的地方，正好和最近的一个项目可以自由发挥，就套用了原本的脚手架项目，并做了一些改进，另外也结合了docker。
首先是总体的项目
|
|-deployment_yml
|-deployment_server
|-deployment_dockerfile
|-project1
|-project2
项目会分为四个部分，第一个部分是yml，也就使用到了docker-compose进行部署，这样做可以减少部署成本，因为yml将相关的container都声明了，部署时只需要一句启动命令即可，启动一个container和两个container的耗时是一样的（当然，这里要有依赖关系，具有依赖关系的container放在一起当然是最好，虽然你可以将所有的container声明都放在一起）。
第二部分是一个服务器文件，如apache/uwsgi的配置都可以以文件的形式保存，在dockerfile里面现场写一份应该并不是明智的选择，所以将这些配置文件都拿出来，再使用git或者mount传递到container内。
第三部分是dockerfile，这个不用多说。
第四部分是项目源码了。
之所以这分配是因为考虑到之后项目可能不使用docker进行部署，当然也有可能更换一个应用服务器，所以将源码、docker、还有服务器配置分开，尽量保持三者的独立性。
再来到项目中（当然说的是django项目）
材料：
django -> wsgi application
webpack -> static bunlder
django restframework -> rest api
mongoengine -> mongo ORM
Vue.js -> MVVM / component / front-end module
bootstrap & vue-strap -> 前端响应式
实际上所有的目标都在于模块化我们的代码，django拥有强大的后台能力，可以让我们的代码更灵活，也提供了足够强大的功能支持。
webpack则是前端的模块化，vue.js所提供了 .vue 单文件化组件功能也必须使用webpack。
mongoengine可以和django进行集成，并且本身的ORM api与django自带的关系型数据库ORM相似
vue-strap和bootstrap帮助我们快速构建响应式的前端页面
|-_config
|-requirement.pip
|-webpack.config.json
|-package.json
|-[project]
|-env.py
|-settings.py
|-urls.py
|-wsgi.py
|-modules
|-app1
|-app2
|-static
|-bundles
|-common
|-core
|-decorator
|-middware
|-model
|-tool
在项目中，大致会分为配置、模块、静态文件（公用）、核心
配置会有requirement.pip 用来记录项目所需的python lib (for pip)
package.json则用来记录项目所需的第三方js库(for npm，大多数第三方js都可以通过npm进行获取，另外也用到webpack)
webpack.config.json-》webpack的配置文件
核心的部分有两块，一块是django的默认项目配置文件如settings / urls / wsgi等
另一块则是项目所需的公用python代码，如修饰器，中间件，模型，工具等等
静态文件有另两部分，一是webpack打包的目标文件夹，一是公用的js或css，例如bootstrap.css则没有必要以webpack的形式打包，或一些难以打包的静态文件，还有一些图片等
模块则是我们的核心代码，因为webpack的关系，我们的前端文件也拥有了模块化的能力，所以可以很好的和我们的后台代码按模块放置在一起。
|-modules
|-base
|-app
|-base.html
|-base.js
|-base.css
|-app1
|-api
|-service
|-domain1.py
|-domain1.py
|-domain2.py
|-app
|-page1
|-component
|-page1.css
|-page1.js
|-page1.html
|-view
|-view.py
这样我们就可以将每个模块的前后端代码放置在一起，又将整个页面分为 api / app / view三层，view负责页面跳转，api负责ajax，app则是webpack下的js代码
