DAO层
负责与数据库打交道的一系列代码。
数据库就是拿来存数据的，通常数据库中的一个数据表对应一个DAO层的对象，该对象的类的命名规则为XxxDAO或者XxxMapper等。DAO对象向上提供对数据表项的增删查改接口，例如（持久化）保存一个对象、删除一个对象、查找一个对象、查找一组对象、更新一个对象等。方便起见，又有一系列的entity类，放在entity包中（DAO类对象放在dao包中），entity对象活在内存里，通常和数据表项一一对应。
着手写代码的顺序通常是：设计数据表>然后实现DAO层>测试DAO层。
DDD
Domain-Driven Design领域驱动设计，简称DDD。从头到尾就没懂。。。。。
暂时的理解：
DDD就是真·面向对象设计。所谓设计领域模型就是进行面向对象设计。
我始终记得think in java里面的两句话“问题的复杂度取决于抽象的质量”、”面向对象设计的技巧在于——将对象视为服务的提供者“，我在写”面向对象代码“的时候基本上是在想这两句话。因此，基于上述不知对错的理解，我认为DDD的缺点在于，一个系统在每个人脑子里抽象出来可能是不一样的，并且，每个人对业务的熟悉程度不同，抽象质量也不同。所以一个人的抽象另外一个人未必能看懂，不利于分工合作（每个人脑子里的系统不容易一致）。而且针对特定业务可能有很多不同的抽象，往往是没有定论的，斟酌来斟酌去可能还是贫血模型简单（几乎是一套固定的模板）。
实践上，我们普遍用的贫血模型就是”数据表驱动开发“，贫血模型里面可以有单纯的没有任何业务的数据对象、也有不带数据的单纯的业务对象。例如User这样子的纯数据对象，就是有name、age等字段，然后只有set和get方法。着手写代码的顺序通常是：设计数据表>然后实现DAO层>测试DAO层。
而DDD步骤则是：先设计好领域模型>再设计数据库。一个领域模型可能对应N张表，例如说商品模型的销量
可能分散在交易成功记录里未必是商品表计数。
总之，贫血模型为主，DDD为辅。
贫血设计 VS. 充血设计
摘自：https://www.zhihu.com/question/20360521/answer/14891150
举个简单的J2EE的例子，设计一个与用户（User）相关的功能，传统的设计一般是：
类：User+UserManager
保存用户调用：userManager.save(User user);
充血的设计则可能会是：
类：User
保存用户调用：user.save();
——User有一个行为是：保存它自己
RESTful API
一句话概括就是：URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作
参考资料：