在整体体系上，通常的后端服务会面临存储，读取，筛选，排序，权限等诸多数据上的处理逻辑。在日常的mvc框架中。通常会把这些操作封装到一些module中以方便调用。而实际的应用场景中会或多或少的遇到一些瓶颈。于是诞生了nosql的概念。
- 什么是
nosql
nosql 其实是 not only sql，对于我们大数据来说。sql的速度还是不够快。于是产生了直接存储文件的方式。如果数据量小，则采用内存存储的方式。对于大公司而言，这都不是问题。加机器。加内存。加ssd，解决问题。比通过技术手段优化代码来的快速而实际效果也很显著。对于中小型企业现在也有更多的云服务可选。有兴趣的可以google下nosql的常用手段和实现方式。
对于存储的数据的拆分筛选经常会设计诸多算法。通常库表中的数据直接读写不再过多的介绍，对于文件存储甚至内存存储的甚至是sql存储的问题在于，我们如何准确快速的同步数据同时保证我们的数据是最新。于是就有了cache的概念。cache相对解决了性能问题，数据不同步问题。但是却引入了实效性问题。而同步cache也引入了是从客户发起请求（第一个连接发起）触发还是自动时效的来触发问题。根据不同的业务也有不同的基础架构。也就是对于缓存机应该是近存储还是近用户的问题。这个问题因我不是专业的后端工程师，也就不再讲述。
数据存好了，我们应该对数据进行操作了。这时候其实我们面临的是如何提供数据服务。通常在mvc中会有专门的一个dao来做这件事情（mvc并不关心数据是怎么来的，怎么去的，只需要知道我有数据，我存储了，我读取了。）。从dao到数据存储的整个体系，是我们的基础服务层，也叫数据层。
在数据层上层是服务层。这个服务是为机群中的业务代码提供服务的，他们会涵盖所有数据的分类查询接口，同时做好数据的整理校验，安全和筛选。这个层是server层。是为业务服务的。（如：数据挖掘，查找用户信息）
业务层会有业务逻辑，权限控制，在整体划分上分上下两层结构，下层提供的接口保持统一，一份用作开放接口以供开放平台使用，而另外一部分接口是拥有更多权限的开放接口，是用来构建自身web的接口。他们以密钥的形式进行比对。更加完善的权限校验机制。丰富的接口，良好的生态环境。也方便ui改版而不影响后端架构。
而上层则配套给view层（前端）做展现。展现逻辑则交给view实现。
后端的业务层（ui层）为前端提供了丰富的接口和对应的数据。任务开始交给前端。
前端的生态环境恶劣，业界也有不少解决方案，知名的当属YUI closure 当然还有更多的。但是dojo jquery这些并不能算解决方案。他们只是一个库，功能较为强大的库。
说说应对业务来做的系统划分：
page 页面。前端应该是纯粹的，简单的，可调试的，快速预览的开发方式。不应该依赖后端框架，应该更加前端化，nodejs是不二选择。
mods 模块，一个页面应该是有一到多个模块构成的。
widget 模块中的一些功能是完全可以多个共用，但是却不算做组件的功能，交给他吧。
assets 我们的libs 以及reset都在这里。每个page下都有自己的assets
layout 页面的框架需要几个布局来实施布局可以互相嵌套（本来打算引入frame的概念，后来想想还是算了，没有必要，有layout足够了）
component 小零件，我更愿意叫它公共组件。是构成页面通用部分的基础组成部分。layout和component当属框架，也就是common中的，这个模块不属于常规页面，是一个特殊的组成。
test 它是自动化测试的脚本文件。
_build 编译脚本
output 物料产出的路径
总的来说，整体的架构尽量保证职能单一原则，每个层面的代码应不对另外的层面产生强依赖，而每个层面尽可能的提供更加简单且丰富的api。
好的架构是美国的手枪，拆卸的零件是可以再组装到别的环境继续使用的。这一切，源自我们共同维护，遵守。