请问如果没有持久化层，还能否存在业务层

这是目前现状，用数据库来替代业务，业务都是扁平化静态化为数据保存在数据库中，而REST基本是数据的修改查询动作，所以，在这个架构中，REST其实充当持久层接口作用，这也是为什么很多持久层技术如NoSQL数据库使用REST作为其调用接口的原因。

因为我们普通都是用REST直接和界面显示挂钩，结合上面REST又是持久层的结构，那么我们的简单架构就变成：界面 + REST + 持久层。

这个架构就像当初MVC一样，简单易用，问题还是灵活性不够，业务都基本钝化成静态数据保存在数据库中，当业务复杂时，我们需要改变上面架构为：界面 + REST + 业务模型 + (REST)持久层。

前面的REST是直接和界面挂钩，后面REST是和持久层接口，所以，REST是一个接口作用在这样架构中非常明显。

另外根据DDD，业务逻辑也不是放在Service中，而是在领域模型如实体相关的模型中。

DDD是针对复杂系统应付变化的一套方法，如果你的系统不复杂，只是数据的CRUD，那么没有必要使用DDD。

你说的将业务逻辑放在Service中，是一种SOA做法，将数据整合作为功能对外提供服务，这种架构个人认为已经失败。

总之，现在有三种架构：REST架构基本可替代过去的SOA架构，这两个都和纯技术有关，把业务看成数据，所以，你基本都是和数据库打交道，这时数据库=业务层+持久层。

当，业务复杂以后，你就不能就技术论技术了，你就必须将业务层和持久层从数据库中解放出来，将计算和存储分离，这就是现在云计算架构。

“一个单词或一个句子所出现的环境，这个环境会反过来影响它们的含义。”这就是名可名，非常名了。模型是边界，就是环境，它决定了内部的所有含义，场景也是边界，也是环境，只不过场景决定的是role和im。而DDD的实体隐含了role了，所以DCI的D叫做DATA，只有成为role了才可以和DDD的实体等价。这样理解不对？

DDD与数据库驱动最大不同在于，从仓储只能查出聚合根。根内的实体，都是通过根来获取，这样的目的是确保一致性。例如，论坛新增了一条帖子，那么论坛的帖子数+1，数据库驱动的话，要么当做一个属性，要么每次当当作统计来查询。DDD的话因为每次都必须通过根来增加，所以根可以更新自己的状态了。数据库也就成为沉睡的地方。

灵活不灵活是与语言相关，与思想无关，思想是讲严谨性的，如你一时说他们有关系，一时说他们没关系，到底有无关系呢？这就是严谨的体现了。也就是根据某个思想，一切都应该可以决定下来的（取舍的除外），否则会出现BUG。

DDD一样有R存在的，通过聚合方式体现而已，当然也有部分Service存在。