请指教我的商户和商户促销信息管理的领域设计!

请指教我的商户和商户促销信息管理的领域设计
一:业务场景
1:系统管理(增删改查)加盟进来的商户, 录入商户的基本信息:商户名称,行业类型,所属区域,
地址,电话
2:系统为加盟进来的商户设定如下特性来在网站前端展示:
最新加盟商户, 推荐商户,商户高级搜索, 热门商户, 商户详细信息
, 商户排行,
3:系统为加盟进来的商户维护促销展示信息,设定一些促销特性质:
商户促销信息, 每周热点.
然后在网站前端展示
4:另外系统前端展示又有一些:公告,重点推荐的公告, 帮助信息.
5:还有一些轮换滚动的flash的促销信息

二:分析
1:分析了一下,其实整个需求都是围绕这商户和其对应的信息来完成的.
2:商户根据行业进行分类,然后又附加了一些商业操作属性.
3:信息从属于某个商户,然后又附加了一些商业操作属性.
4:公告和滚动的flash其实也是一种信息.

系统四色图如下:


不知道为什么图片上传老是出错!


请指教我的领域设计!

请指教我的领域设计!


请指教我的领域设计!

根据DDD进行设计:
1:为实体: Shop ,ShopType, News, NewsType, UploadFiles, FilteredWords ,分别添加仓储
2:寻找聚合根:
聚焦于大层面上来看:Shop是一个聚合根
聚焦于信息来看News是一个聚合根
3:约束如果Shop没有被启用,那么对应聚合体内的操作都不能够被执行

请多指教!

我没有看懂News代表什么。是代表公告吗?
我认为只有聚合根对象需要仓储,而像ShopType这样的对象基本除了CRUD外,没有针对它的业务操作,认为不需要仓储。
另外从您的分析来看(一楼二、分析),您认为商户是根据行业分类,但是从需求场景来看,没有明确的体现这一点,那么是不是在这个问题里,行业也仅仅算是个state?

首先非常感谢freebox的讨论!
<我没有看懂News代表什么。是代表公告吗
>News泛指为商户做的促销信息,公告,帮助信息.,统一称为News,以后可能还会有新的信息类型加入.所以单独抽出了一个NewsType.
加入信息的目的是因为网站方要为商户方做一定的宣传., 信息太多就需要组织管理
<我认为只有聚合根对象需要仓储,而像ShopType这样的对象基本除了CRUD外,没有针对它的业务操作,认为不需要仓储
确实只有CRUD操作
<另外从您的分析来看(一楼二、分析),您认为商户是根据行业分类,但是从需求场景来看,没有明确的体现这一点,那么是不是在这个问题里,行业也仅仅算是个state?
需求中有” 录入商户的基本信息:商户名称,行业类型”, 也就是是说商户要按照比如”大卖场, 餐饮, 健身…”
这样的类型来划分的.而且行业的类型会不断的增加.所以就单独拉出来了一个ShopType

我觉得需要考查行业类型是不是属于泛类型,比方说有行业类型交叉,商户A同时属于两个级别对等的行业类型怎么办?而且在您的需求里只是录入一下,更多的相关于行业类型的操作没有体现,是否应该把它直接设计进Shop的属性里,像是否是热门那样,而不是单独的对象概念?
对NewsType的感觉同上。
FilterWords和FilterWordsService从字面上感觉是敏感词汇过滤,FilterWordsService是不是仅仅负责CRUD?(因为实际过滤对象是News,应该扔进News的相关作业里。)并且这块应该不是任何人都能接触到的,只有管理员才负责,而且我觉得这样的词汇也不会太多,感觉应该建xml过滤表,在应用里直接解析xml成Set并放进全局缓存里,更新xml的时候提供一个重新载入功能来更新缓存。因为感觉这个和业务关系不是很密切,只是为业务提供一批资源而已。我们对于少量的、修改不频繁的、全局应用的资源都是这么做的,但不清楚这方式对您是否合用。

<我觉得需要考查行业类型是不是属于泛类型,比方说有行业类型交叉,商户A同时属于两个级别对等的行业类型怎么办?而且在您的需求里只是录入一下,更多的相关于行业类型的操作没有体现,是否应该把它直接设计进Shop的属性里,像是否是热门那样,而不是单独的对象概念
>在我们的业务需求中根据行业来划分商户的需求是存在的。需要根据行业提供对不同行业商户
信息的检索和统计。现在的设计确实划分的比较粗。

<FilterWords和FilterWordsService从字面上感觉是敏感词汇过滤,FilterWordsService是不是仅仅负责CRUD?(因为实际过滤对象是News,应该扔进News的相关作业里。)并且这块应该不是任何人都能接触到的,只有管理员才负责,而且我觉得这样的词汇也不会太多,感觉应该建xml过滤表,在应用里直接解析xml成Set并放进全局缓存里,更新xml的时候提供一个重新载入功能来更新缓存。因为感觉这个和业务关系不是很密切,只是为业务提供一批资源而已。我们对于少量的、修改不频繁的、全局应用的资源都是这么做的,但不清楚这方式对您是否合用。
>你说的和我们的设计思路是一致的。至于敏感词的存储,其实那里都可以的。

分析设计得很好,结合四色原型和DDD,而且确定了聚合跟。

>聚焦于大层面上来看:Shop是一个聚合根
>聚焦于信息来看News是一个聚合根

Shop可以看成是News的容器,就像JiveJdon中Thread是Message的容器一样。

基本没有什么问题,代码也同时出来了,这就是模型驱动设计MDD的好处,也是敏捷XP的优势,模型出来了,代码文档都蕴含在后面,只要通过together这些工具导出就可以。

不好意思,你的模型不能算领域模型

楼上可能有些误解,楼主的图实际是四色原型+DDD的领域模型图。可能有Jdon特色吧。

不知楼上是否详细谈谈自己的认识呢?百花齐放。

我看了一下,至少添加、删除等不要在这个模型中出现 吧,其次根据需求可以看到应该包括一个时刻时段,用户注册;(我没有看到提供给用户什么服务,所以可能是需求描述漏了吧)

用户管理领域在系统的用户管理里面体现,这是一个内部维护商户信息的系统,不存在注册功能.所有系统的使用人员和人员的角色授权
都在用户管理里面了,只有经过对应角色授权的用户才能使用系统的业务功能.就是说系统用户管理权限分配的功能是和业务功能
单独分开来的.所以这里也没有体现.应该说在四色图中是有一个用户角色的.呵呵,越来越像jivejdon的模型了.我这也是复用优秀的模型和
设计来解决自己业务中的问题么,呵呵!学习中

为什么ShopType和NewsType被设计成了PPT,为什么不是Description? 我感觉设计成Description更合理点呀。