领域驱动设计--小需求的疑问。望大神帮忙。

                   
zpp2025
13-02-28 17 1531 6

目前需求:1.用户可以关注店铺
2.店铺每天都有动态信息推送到系统中
3.用户可以查看最新动态(当然是自己关注店铺的动态列表)
其他的需求不继续详细说明。

我根据需求画了usercase 概括了需求内容。


我的分析的实体如下:


存在的问题:
1.用户进来之后要看自己关注过的店铺动态,因为动态是属于店铺实体的。那这样的话,关注-->店铺-->动态,按照这种方式来查询数据了。貌似有些不拖。因为动态数据多的话需要分页。
如何将 关注 和 动态 比较好的建立关系? 或者这部分数据是需要通过领域之外的方式来查询处理?
2.一直存在的困惑,就是持久化操作,比如说这个需求里面 的店铺有动态,那么我的店铺可以增加个动作来删除动态,那这操作之后数据持久化怎么做?领域操作的对象难道要在自己的领域方法里面直接调用持久化的 respository么?还是通过消息通知方式来做?如果消息通知的方式来做持久化操作,那如果保证事务完整性。

6
banq
2013-02-28 13:46

2013-02-28 12:51 "@zpp2025
"的内容
关注 和 动态 比较好的建立关系? 或者这部分数据是需要通过领域之外的方式来查询处理 ...


首先,领域模型的高聚合关系是反映业务领域本质的旋律,当然,如何实现方便的查询也是考量之一,查询是一种只读操作,关系主要为写操作而设计,读操作可以借助直接对Repository查询。

至于第二个问题,使用消息带来事务问题,引入Event Sourcing,也就是将每个事件持久化保存,必要时进行回滚播放追溯,这种方式可以替代传统刚性的使用架构技术的事务,Event Sourcing是一种偏业务的非常自然的事务。

zpp2025
2013-02-28 14:11

感谢@banq 的回复
我的活跃店铺量在200W左右,如果店铺下面直接挂入动态。每天就算是1个动态。也至少200W个店铺动态。
这样的话我在数据持久化方面如果使用数据库存储势必会做分表。如果做分表就是使用店铺id作为分表的字段。

1.那这样就存在一个查询问题。一个登陆用户要看他所有关注的店铺的动态信息。登陆用户-->店铺动态信息。如果查询就存在跨表的合并数据问题,这样查询效率肯定不可取。
2.那这样的话,我会重新设计一个实体出来,关注动态? 来以人的维度来存储关注店铺的动态信息。如果这样做就会造就出非常多的冗余数据出来。A,B,C 三个人都关注了店铺,店铺如果有了动态消息之后,按照这样的设计就会分发给A,B,C三个人每人一条消息,那假如一个店铺被关注超过10w,那岂不是光一个店铺就要发送10w条消息出去,这样的设计势必造成很大的系统压力和数据冗余。

所以banq老师,有木有比较好的方式处理这种业务模型
[该贴被zpp2025于2013-02-28 14:15修改过]
[该贴被zpp2025于2013-02-28 14:16修改过]

banq
2013-02-28 14:32

2013-02-28 14:11 "@zpp2025
"的内容
所以banq老师,有木有比较好的方式处理这种业务模型 ...


你这个问题是因为动态信息量大引起的,这里我们先分辨一下店铺动态信息如果设计为值对象,也就是一旦发布,不允许修改,那么我们可以通过值对象共享的方式分享给那些关注的人,可以让关注者不断访问内存中店铺状态,如果一旦有新的动态信息,关注者进行读取即可。



flyzb
2013-03-02 10:41

从你的用例图可以看出,显然不是小需求,而是大系统。

从领域驱动设计的角度看,用例图分析中的界(也就是领域)的划分不太明显,这样可能对系统可扩展性不利。

关于商铺的动态信息,其实就是一个商铺报表。如果做成实体,显然是一种数据库级的数据冗余。如果直接放到内存里,查询速度应该没有问题,当然还可以考虑缓存复制。一般流量下,内存更新是很快的;如果流量大,可以考虑内存分区和集群。



[该贴被flyzb于2013-03-02 11:09修改过]

4Go 1 2 3 4 下一页