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

11-03-22 wqs918
我经常用到一般都是STRUTS+WEBSERVICE 或者是SSH框架，我总是感觉写来去就是为了和DB打交道，利用CURD组织成画面的数据，我完全感觉不到业务逻辑是在SERVICE层，SERVICE根本不像对象，更像是一个函数库，
对于WEB开发，业务逻辑明显是存在数据库里，而画面就是业务逻辑的直观体现，至少我现在感觉REST的开发模式更适合WEB开发，而所为的SERVICE层DAO层，有点脱裤子放屁的感觉，当然我初识DDD，我的想法一定是挺肤浅的，但对我来说确是真实的，所以，恳请道长指点迷津，先谢谢了

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

banq
2011-03-23 08:55
2011年03月22日 23:16 "wqs918"的内容
对于WEB开发，业务逻辑明显是存在数据库里，而画面就是业务逻辑的直观体现 ...


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

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

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

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

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

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

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

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

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

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

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

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

SpeedVan
2011-03-29 09:47
ER图也是有边界思想的，所以和类图很相似。但它缺少职责概念，而且没有强调内聚。

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

wqs918
2011-03-29 13:19
「DDD与数据库驱动最大不同在于，从仓储只能查出聚合根。」可谓一语中的，令我茅塞顿开啊，可这更让我感觉不到DDD的先进性了，按照仁兄您的说法，DDD和DB的区别，更像是用JAVA还是用C＋＋，一个规范，一个灵活，，还有就是，利用DDD，那数据库的设计应该在什么时候呢，数据的设计应该独立与DDD，单独设计吗，还是根据DDD设计出来的对像，然后再设计数据库呢，还有ER图中的E，DDD设计出来的E，是不是应该一致呢，我感觉我开始懂了，可是还没懂，还请再给指点一二，谢谢

wqs918
2011-03-29 13:19
「DDD与数据库驱动最大不同在于，从仓储只能查出聚合根。」可谓一语中的，令我茅塞顿开啊，可这更让我感觉不到DDD的先进性了，按照仁兄您的说法，DDD和DB的区别，更像是用JAVA还是用C＋＋，一个规范，一个灵活，，还有就是，利用DDD，那数据库的设计应该在什么时候呢，数据的设计应该独立与DDD，单独设计吗，还是根据DDD设计出来的对像，然后再设计数据库呢，还有ER图中的E，DDD设计出来的E，是不是应该一致呢，我感觉我开始懂了，可是还没懂，还请再给指点一二，谢谢

SpeedVan
2011-03-29 17:57
数据库也有一致性的，DDD可以说把一致性提取出来（其实在OO里，本就不应该放进去的）。DDD是一种纯OO设计，它本身是没有数据库概念的，没有先后一说。但因为表不能决定实体，所以一般把数据库放在后面，某些时候可以用用正向工程，有时还是不适合的。

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

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

猜你喜欢