DDD问题
DDD提倡通过聚合的根来访问聚合中的其他领域对象.我有个疑惑,比如产品管理,产品需要分类.所以就有两个领域对象一个是Product,另一个是Category.这个聚合的根应该是Product吧(如果为Category的话,供应商之类的就没法处理了.).那么我的问题是,如果我需要一个产品类别的列表,然后用户可以通过产品类别的列表来查看列表下的产品,那么我怎么通过这个聚合的跟来访问到产品类别的列表?
(本人初涉DDD,问题特小白,请大家拍砖.)
没人回答我的问题?....
2009年12月23日 20:35 "xiaoqianglinsen"的内容
那么我怎么通过这个聚合的跟来访问到产品类别的列表?
(本人初涉DDD,问题特小白,请大家拍砖.)
(本人初涉DDD,问题特小白,请大家拍砖.)
product.getCategorys不是就可以吗？
我觉得Category自己就是一个聚合，自己就是聚合根。
当product.getCategroys想要取得当前这个product的类别的时候
利用domain events，通过Category的Repository获取
不知道这样行不……
2009年12月24日 14:35 "banq"的内容
2009年12月23日 20:35 "xiaoqianglinsen"的言论
那么我怎么通过这个聚合的跟来访问到产品类别的列表?(本人初涉DDD,问题特小白,请大家拍砖.)product.getCategorys不是就可以吗？
那么我怎么通过这个聚合的跟来访问到产品类别的列表?(本人初涉DDD,问题特小白,请大家拍砖.)product.getCategorys不是就可以吗？
如果从Product.GetCategories()来获取这个列表的话,就意味着我需要在列出Category列表之前获取到Product对象的一个实例.然而常理是:我们需要先列出Category列表,然后通过选取列表来浏览列表下的Product
道如是说:软件依赖于常理...
2009年12月24日 16:45 "hzgnjupt"的内容
我觉得Category自己就是一个聚合，自己就是聚合根。当product.getCategroys想要取得当前这个product的类别的时候利用domain events，通过Category的Repository获取不知道这样行不……
(1):Category自己是一个聚合,这个不敢苟同.
(2):使用domain events不错,但是还是需要先有product才能获取到Category列表,很显然,我们的常理是现有Category列表才能显示相应的Category下面的Product列表.
2009年12月24日 21:47 "xiaoqianglinsen"的内容
如果从Product.GetCategories()来获取这个列表的话,就意味着我需要在列出Category列表之前获取到Product对象的一个实例
DDD有两种方式：第一种通过聚合根获得，第二种直接通过Repository查询获得。
Category列表通过后者实现，而输入product表单时通过聚合根获得。
实际就是查询和命令分开模式：CQRS 使用CQRS重新考虑架构
Category c = new Category();
c.name = "巧克力"；
Category cb = new Category();
cb.name = "奶油巧克力";
c.addChild(cb);
Product p = new Product();
p.name="DOVE";
p.price = 11.11
p.category = cb;
供应商应该是别的对象吧。
不能把他们混为一谈吧。
当然，跟他们会有某种关系。
按照他们的特点找出那种关系。
但是，我觉得这应该不太难
你觉得呢？
谢谢诸位,我只是想验证一下我的想法.
我的想法是这样的.
(1)如果是有关业务逻辑和领域相关的操作则尽量从聚合的跟来访问,而Category列表本身没有业务逻辑的意思.也不属于领域行为.
(2)根据切入点的不同,领域对象聚合的根也是不同的,如果我们现在需要维护的是Category那么切入的跟就是Category而不是Product,如果需要维护Product那么切入的跟就是Product而不是Category.
自己对(2)颇有怀疑.
2009年12月23日 20:35 "xiaoqianglinsen"的内容
如果我需要一个产品类别的列表,然后用户可以通过产品类别的列表来查看列表下的产品
个人觉得Category可以作为一个Aggregate Root.
和楼主同样的疑问，banq能不能给我们详细分析下再上个图呀，我是菜鸟
好问题，我也觉得应该是cqs.
楼主描述的功能，根本够不成业务行为，这是UI和presentation做的事，直接返回DTO了事，我个人以为连repository都不需要走的。如你的这个问题，我直接走app service返回所有的product和Category（如果数据不常变，app service缓存之），剩下的事由展现端搞，不知Banq意下如何？
我的认知是，如果一个功能不能用一句业务化的命令定义，则这个功能根本与domain无关。这可能是cqs给我最深刻的体会。
[该贴被FredWang于2010-06-10 22:42修改过]
These reports will never be updated directly by the consumer of these reports, the data represents the state of the domain, so the domain is responsible for updating it. So all we really do on this side is report the current state of the system to who or what ever needs it.
When an application is requesting data for an specific screen than this should be done in one single call to the Query layer and in return it will get one single DTO containing all the needed data. Now because of this specific use of the data it makes sense to order and group it in such a way that is determined by the needs of the system. So we de-normalizing the data trying to make a single table reflect a single screen or usage in the client application. The reason for this is that data is normally queried many times more than domain behavior is being executed, so by optimizing this you will enhance the perceived performance of the system.
引自CQRS à la Greg Young，我觉得写的很精彩