一个领域内存在许多实体，他们都在仓储里面待命中。当业务发生时，相关实体就会进入发生的业务场景进行交互。业务的完成会引起实体的诞生、消亡和状态的迁移。这当中没有DB概念，仓储就如一个实体集合，它已经把DB屏蔽了。当然了，好的仓储是关键了。

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

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

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

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

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

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

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

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

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

若果建立模型时，则看到底把业务逻辑放在哪里，放在service则是service相当于context，放在模型则模型就是context（界限上下文）。个人感觉，DDD的模型=实体+逻辑，以内聚的方式实现。DDD不需要场景代码来支援，因为模型就是场景了。

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

banq 老师的分析确实让我看清了为什么我现在写的代码是这种感觉的，可是真正DDD的业务真的就能放到数据库以外，我同意SpeedVan 兄的说法，仓储的设计最重要，因为按照DDD的步骤是先分析好聚合的实体，然后设计仓储，而仓储是什么，它就是关系数据库的封装，仅仅是把select变成get,把insert变成add,把delete变成remove，数据库又是ER图的物理实现，ER图恰恰的实体关系图，那我是不是可以认为DDD的目的就是为了画出一个ER图呢，那这各数据库驱动的开发方法，应该是一曲同工，并无优劣之分啊，我不知道我的分析对不对，请先辈赐教