尽管已经研究Domain Driven Design了很长时间,但我仍然有一些基本要素.
似乎每一次我尝试设计了丰富的时候domain layer,我还需要大量的Domain Services或厚Application Layer的,我从"GetTotalAmount"等结束了,在他们没有真正的逻辑一堆近贫血域的实体,除了.关键问题是实体不了解外部因素,并且向实体注入任何内容都是不好的做法.
让我举几个例子:
1.用户注册服务.用户持久存储在数据库中,生成并保存文件(用户帐户需要),并发送确认电子邮件.
确认电子邮件的示例已在其他主题中进行了大量讨论,但没有得出真正的结论.有人建议把逻辑的application service是得到一个EmailService和FileService注入从infrastructure layer.但那时我会在域外拥有业务逻辑,对吧？其他人建议创建一个domain service得到infrastructure services注入 - 但在这种情况下,我需要有(和)infrastructure services内部的接口看起来不太好(因为不能引用).其他人建议实施Udi Dahan的域事件,然后让EmailService和FileService订阅这些事件.但这似乎是一个非常松散的实现 - 如果服务失败会发生什么？请告诉我您认为正确的解决方案.domain layerIEmailServiceIFileServicedomain layerinfrastructure layer
2.从数字音乐商店购买歌曲.购物车已清空.购买持续存在.付款服务被呼叫.发送电子邮件确认.
好吧,这可能与第一个例子有关.这里的问题是,谁负责编排这笔交易？当然,我可以通过注入服务将所有内容放入MVC控制器中.但如果我想要真正的DDD,所有业务逻辑都应该在域中.但是哪个实体应该采用"购买"方法？Song.Purchase()？Order.Purchase()？OrderProcessor.Purchase()(域名服务)？ShoppingCartService.Purchase()(申请服务？)
在这种情况下,我认为在域实体中使用真实的业务逻辑非常困难.如果向实体注入任何东西不是好的做法,那么除了检查自己(及其聚合的)状态之外,他们怎么做其他事情呢？
我希望这些例子足够清楚,以显示我正在处理的问题.