banq
2013-01-19 16:35

非常不错,恭贺一下,创新精神可嘉。具体细节需要详细了解和讨论。

gameboyLV
2013-01-19 16:56

2013-01-19 14:36 "@flyzb"的内容
既然是”领域服务“,那就是领域层对外的被调用接口,也就是领域的逻辑外观,但'领域服务"在本图中是被“仓储”调用而与领域对象无关。 ...

Eric Evans的《领域驱动设计》一书中68页有这么一段对领域服务的介绍:

“一些领域概念不适合被建模为对象,如果勉强地把这些重要的领域功能划分为Entity或Value Object的职责,那么不是歪曲了基于模型的对象的定义,就是人为地增加了一些无意义的对象。”

很明显领域服务并不是领域的边界,而是与领域对象处于同一层次。场景上下文才是领域的边界。同样是这本书的236页有这么一段:

“明确地定义模型所应用的上下文。根据团队的组织、软件系统的各部分的用法以及物理表现来设置模型的边界。在这些边界中严格保持模型的一致性,而不要受到边界之外问题的干扰和混淆。Bounded Context明确地限定了模型的应用范围。”

[该贴被gameboyLV于2013-01-19 16:58修改过]

flyzb
2013-01-19 22:03

DDD中的”上下文”实际上指的领域模型的一致性和完整性,而不是指功能边界,从14章的图14-3和图14-4的那个例子更可以明确地看出来。

另外,你引用的那段”领域服务“的话只是说明领域服务的逻辑与领域对象和值对象的不同。你应该好好领会一下”服务“的基本含义:

服务是指为他人做事,并使他人从中受益的一种有偿或无偿的活动。不以实物形式而以提供劳动的形式满足他人某种特殊需要。

对于”领域服务“,就是领域模型为应用层做事的。

[该贴被flyzb于2013-01-19 22:11修改过]

gameboyLV
2013-01-20 09:53

2013-01-19 22:03 "@flyzb"的内容
对于”领域服务“,就是领域模型为应用层做事的。 ...

应该是为领域层做事的才对,14-3那个图预订Context是实线,实线表示某种物理存在的事务,预订Context应该就是一套与其他Context进行通讯的API。

14-3这里例子似乎有歧义,你说RoutingService对外服务也许,对内服务也行,但是。。。另外一个例子就没有歧义了:

Jimmy Nilsson《领域驱动设计与模式实战》182页

//Order
public void Accept()
{
  if(_status != OrderStatus.NewOrder)
    throw new ApplicationException("You can only call Accept() for NewOrder orders");
    
    _status = OrderStatus.Accepted;
    _orderNumber = _orderNumberService.GetNextOrderNumber();
}
<p>

这段代码正好与Eric Evans的观点相互印证:

“一些领域概念不适合被建模为对象,如果勉强地把这些重要的领域功能划分为Entity或Value Object的职责,那么不是歪曲了基于模型的对象的定义,就是人为地增加了一些无意义的对象。”

因为OrderNumberService实际上是一个锁机制,所以不适合放在Order对象中,我就不信OrderNumberService还能为应用层做事?脱离了Order的OrderNumberService没有任何意义。

banq
2013-01-20 11:20

我认为两位对服务的看法都有道理,Eric Evans还认为服务是一个无副作用的函数,输入参数和输出结果能够确定,符合契约设计DBC:Design by Contact,因此易于测试,采取断言方式进行测试,而测试的输入参数和输出结果正好是DDD设计的两个领域模型。

楼主这个系统其实有两个服务,一个显式画出来,服务于实体模型;还有一种是隐式的,也就是API接口,实际可能就是一种服务,或者场景A出也可能是@flyzb 认为的服务。

以上只是个人见解。

6Go 上一页 1 2 3 4 5 6 下一页