领域驱动设计是否需要在领域对象之外实现业务逻辑。
The model of the domain are my entities used as POCOs which means no base class, no interfaces around and no Attributes.
So the business logic like validation rules must be outside of the entities. (Anemic Domain Model)
Would this comply with Domain Driven Design?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，不是真的。
领域驱动设计的主要目标是尽可能明确地在模型中捕获和封装业务领域。业务总是包含行为，因此 - 你的对象也应该有行为。
...并且不应使用 c#、.net clr。这就是基础设施，对吧？ ;)
这些是表达您的模型的工具。您应该尝试降低噪音水平，分离您的模型，但您将无法完全失控，因为它是用编程语言和周围技术表达的现实生活模型。
顺便说一句，您可能想研究永远不允许域对象处于无效状态的想法。如果感觉这种特殊类型的验证与业务无关，那么它首先就不应该出现在领域模型中。
No. Not really.
Main aim of domain driven design is to capture and encapsulate business domain in model explicitly as possible. Business would always contain behavior, therefore - Your objects are supposed to have behavior too.
...and no c#, .net clr should be used. that's infrastructure, right? ;)
Those are tools to express Your model. You should try to keep noise level down, separate Your model, but You won't be able to runaway completely because it's a model of real life expressed in programming language and technology around it.
Btw, You might want to investigate idea of never allowing domain object to be in invalid state. And if it feels that this particular kind of validation does not relate to business - it is not supposed to be in domain model first of all.
这真是一个哲学问题。我真的很想给出一个同样哲学的答案，所以这里是：
正如我所理解的领域驱动设计，最重要的是，无论谁知道某事，都可以用这些知识来做事。我相信这与这篇文章交织在一起。
考虑到这一点，您的普通旧对象应该具有执行其“生或死”的方法 - 重要任务（这会使您的解决方案错误）。
但是，另一种看待它的方式是，这些普通的旧对象是最小的可用数据集，几乎就像基元一样。然后发生的事情是，拥有这些数据对象的对象，它们是域驱动设计中的实际模型对象。并且它们不必完美关联（这将使您的解决方案正确）。
如果模型和数据层是由两个完全独立的设计师设计的，或者如果一个人能够互换角色，那么这种情况很容易发生。或者也许是一点...... wohoooooo D：不过我认为这可能是一件好事！让我举个例子：
论坛
我们现在正在研究一个与数据层有些不同步的模型对象。它将包含业务逻辑来从给定的数据对象计算所需的数据，然后它将能够使用视图所需的数据加载某种视图。模型中不需要 getter 或 setter，因此封装永远不会被破坏。模型对象符合领域，这应该取决于可用性需求，而不是数据存储的限制。数据对象符合旧的数据存储风格。
这将为我们提供数据抽象层（带有 pocos）、mvc、和领域驱动设计。赢？ :)
That's a really philosophical question. I really want to give an equally philosophical answer, so here goes:
As I have understood domain driven design, the most important thing is that whoever knows something, does things with that knowledge. I believe this to be intertwined with this article.
With this in mind, your plain old objects should have the means of performing their "life or death" - important tasks (which makes your solution wrong).
However, another way of looking at it would be that these plain old objects are the tiniest available sets of data, almost like primitives. What happens then is that the objects owning these data objects, they are the actual model objects within the domain driven design. and they don't have to correlate perfectly (which would make your solution correct).
This could easily happen if the model and the data layer are designed by two completely independent designers, or if one person is capable of switching hats. Or maybe be a little.... wohoooooo D: i'm thinking this could be a good thing though! let me give an example:
A forum
We are now looking at a model object which is somewhat out of sync with the data layer. It will contain business logic to calculate the needed data from the given data objects, and then it will be able to load some sort of view with the data that the view wants. No getters or setters will be needed in the model, so capsulation is never broken. The model object conforms to the domain, which should be dependant on the usability demands, not the limitations of data storage. The data objects conform to the old data storing style.
This would give us a data abstraction layer (with the pocos), mvc, and domain driven design. win? :)