领域驱动设计令人困惑
1) 什么是BLL 服务？它们和Service Layer服务有什么区别？什么属于领域服务，什么属于服务层？
2）我如何重构 BBL 模型以赋予其行为：Post 实体保存反馈集合，这已经使得可以通过 feedbacks.Add 添加另一个 。显然，普通的博客应用程序中没有计算。我应该定义一个方法来在 Feedback （反馈）Post 实体中添加 Feedback 吗？或者这种行为应该由相应的服务来维护？
3）我应该使用 Unit-Of-Work （和 UnitOfWork-Repositories）模式，如 http://www.amazon.com/Professional-ASP-NET-Design-Patterns-Millett/dp/0470292784 或者使用 NHibernate ISession 就足够了？
1) What are the BLL-services? What's the difference between them and Service Layer services? What goes to domain services and what goes to service layer?
2) Howcome I refactor BBL model to give it a behavior: Post entity holds a collection of feedbacks which already makes it possible to add another Feedback thru feedbacks.Add(feedback). Obviosly there are no calculations in a plain blog application. Should I define a method to add a Feedback inside Post entity? Or should that behavior be mantained by a corresponing service?
3) Should I use Unit-Of-Work (and UnitOfWork-Repositories) pattern like it's described in http://www.amazon.com/Professional-ASP-NET-Design-Patterns-Millett/dp/0470292784 or it would be enough to use NHibernate ISession?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
1)
业务层和服务层实际上是同义词。 “官方”DDD 术语是应用层。应用层的作用是协调域服务和域模型之间的工作。例如，这可能意味着应用程序函数首先通过存储库加载实体，然后调用该实体上将执行实际工作的方法。2) 有时，当您的应用程序主要由数据驱动时，构建功能齐全的
域模型可能看起来有点大材小用。然而，在我看来，当您习惯了领域模型时，这是您想要的唯一方法。在
Post和Feedback情况下，您从一开始就需要一个AddFeedback(Feedback)方法，因为它会减少耦合（您不需要例如，必须知道FeedBack项是否存储在List中或Hashtable中），它将为您提供一个很好的扩展点。如果您想要添加一个检查，不允许超过 10 个反馈项目，该怎么办？如果您有AddFeedback方法，您可以轻松地在一个点中添加检查。3)
UnitOfWork和Repository模式是 DDD 的基本组成部分。我不是 NHibernate 专家，但将基础设施特定的细节隐藏在接口后面总是一个好主意。这将减少耦合并提高可测试性。1)
Business LayerandService Layerare actually synonyms. The 'official' DDD term is anApplication Layer.The role of an
Application Layeris to coordinate work betweenDomain Servicesand theDomain Model. This could mean for example that an Application function first loads an entity trough aRepositoryand then calls a method on the entity that will do the actual work.2) Sometimes when your application is mostly data-driven, building a full featured
Domain Modelcan seem like overkill. However, in my opinion, when you get used to aDomain Modelit's the only way you want to go.In the
PostandFeedbackcase, you want anAddFeedback(Feedback)method from the beginning because it leads to less coupling (you don't have to know if theFeedBackitems are stored in aListor in aHashtablefor example) and it will offer you a nice extension point. What if you ever want to add a check that no more then 10Feedbackitems are allowed. If you have anAddFeedbackmethod, you can easily add the check in one single point.3) The
UnitOfWorkandRepositorypattern are a fundamental part of DDD. I'm no NHibernate expert but it's always a good idea to hide infrastructure specific details behind an interface. This will reduce coupling and improves testability.我建议您首先阅读 DDD 书籍或其其简短版本对 DDD 的构建块有基本的理解。不存在 BLL 服务或服务层服务之类的东西。在 DDD 中，您有
所有这些层中都可以有服务。服务只是为许多其他对象提供行为，它没有状态。例如，域层服务是您放置不属于任何特定域实体和/或许多其他对象所需的内聚业务行为的地方。它提供的操作的输入和输出通常是域对象。
无论如何，每当一个操作从领域的角度来看似乎完全适合实体时（例如向帖子添加反馈，这会转换为 Post.AddFeedback() 或 Post.Feedbacks.Add( ）），我总是这样做，而不是添加一个只会将行为分散在不同地方并逐渐导致贫血领域模型的服务。可能会有例外，例如向帖子添加反馈需要在许多不同的对象之间建立连接，但这里的情况显然不是这样。
I suggest you first read the DDD book or its short version to get a basic comprehension of the building blocks of DDD. There's no such thing as a BLL-Service or a Service layer Service. In DDD you've got
There can be Services in all these layers. A Service is just there to provide behaviour to a number of other objects, it has no state. For instance, a Domain layer Service is where you'd put cohesive business behaviour that does not belong in any particular domain entity and/or is required by many other objects. The inputs and ouputs of the operations it provides would typically be domain objects.
Anyway, whenever an operation seems to fit perfectly into an entity from a domain perspective (such as adding feedback to a post, which translates into Post.AddFeedback() or Post.Feedbacks.Add()), I always go for that rather than adding a Service that would only scatter the behaviour in different places and gradually lead to an anemic domain model. There can be exceptions, like when adding feedback to a post requires making connections between many different objects, but that is obviously not the case here.
您不需要在 NHibernate 会话之上使用工作单元模式：
为什么我要在 NHibernate 会话之上使用工作单元模式？
在中使用工作单元设计模式/NHibernate会话MVVM WPF
You don't need a unit-of-work pattern on top on the NHibernate session:
Why would I use the Unit of Work pattern on top of an NHibernate session?
Using Unit of Work design pattern / NHibernate Sessions in an MVVM WPF