关于领域模型和领域模型的问题他们的知名度
我参与了一场关于领域模型和领域模型可见性的有趣辩论。想知道这里的人是否有什么好的指导。
- 根据我对 MDA 的理解，我们不需要在整个应用程序层和应用程序层中公开域模型。层
- 原因是对领域模型的任何更改都会对整个应用程序产生影响
- 明智的做法是公开轻量级对象（DTO），它们是领域模型的一个小子集，用于抽象实际模型
- 另一方面，对域模型的任何更改都意味着更改整个应用程序中的各种 DTO，以使更改可见，而如果我们确实公开域模型，则更改将发生在单个位置
。对此的想法。
感谢所有的帮助！
I was involved in an interesting debate about the visibility of domain models & was wondering if people here have any good guidance.
- Per my understanding of MDA, we need not expose the domain model throughout the application layers & tiers
- The reason being that any change to the domain model has an impact in the overall application
- The wise thing to do would be to expose light-weight object (DTO's) which are a small sub-set of the domain model to abstract the actual model
- On the flip side, any change to the domain model would mean changing various DTO's throughout the application for the change to be visible, while if we do expose the domain model, then the change is in a single location
Hope to see some comments & thoughts about this.
Appreciate all the help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不，这不是 MDA 的目的。它是将自己与特定平台隔离开来，使用更高级别的符号（UML 及其操作语言）来指定系统的行为。
是否应该公开域模型取决于应用程序。对于经常使用应用程序的用户（想想你的 IDE），域模型是清晰公开的，你可以直接操作该域中的对象。但对于偶尔使用的应用程序（想象一下机场办理登机手续的自助终端），那么该应用程序应该引导用户完成工作流程。
即使您要屏蔽域对象，DTO 也不一定是必要的；这取决于域对象是否与呈现 UI 的层位于同一进程空间中。需要 DTO 的架构不太擅长适应新的需求，因为它们违反了 DRY 原则。
事实上，可以仅使用直接公开的域对象来构建企业应用程序；这就是裸对象模式的目标。有几个开源框架可以实现这一点，包括最初的 Naked Objects Framework（基于 Java）。还有一个 .NET 的商业版本。
有关领域对象的更多一般讨论，我建议您查看 Evans 的书《领域驱动设计》。雅虎上还有一个活跃的新闻组。
Dan
全面披露：我是 Java NOF 的提交者，不直接参与 .NET 版本。
No, that isn't what MDA is about. It's about insulating oneself from specific platforms, using a higher level notation (UML and its action language) to specify the behaviour of the system.
Whether you should expose your domain model depends on the application. For users who use the application regularly (think about your IDE), then the domain model is clearly exposed, and you manipulate the objects in that domain directly. But for an app used occasionally (think about a kiosk at an airport for check-in) then the app should guide the user through the workflow.
Even if you are going to shield the domain objects, DTOs aren't necessarily necessary; it depends on whether the domain objects are in the same process space as the layer that renders the UI. Architectures that require DTOs aren't very good at adapting to new requirements, because they violate the DRY principle.
It is, in fact, possible to build enterprise apps solely out of directly exposed domain objects; this is the objective of the Naked Objects pattern. There are several open source frameworks that implement this, including the original, Naked Objects Framework (on Java). There's also an commercial equivalent for .NET.
For more discussion in general on domain objects, I recommend you check out Evans' book, Domain-Driven Design. There's also an active newsgroup up on yahoo.
Dan
full disclosure: I'm a committer to the NOF for Java, not directly involved in the .NET version.
我同意丹的观点。解决这个问题的一种方法是使用接口。您使公共方法返回域对象最初实现的接口。当您发现从应用程序返回域对象不再有效时，您可以引入 DTO 并实现相关接口。虽然您的库的内部结构现在已发生变化，但任何消费应用程序都不会受到影响。
I concur with Dan. One way of tackling this is to use interfaces. You make your public methods return an interface which your domain objects initially implement. When you find that returning your domain objects from your application is no longer working you introduce your DTOs and implement the relevant interface. Whilst the internals of your library have now changed any consuming applications will remain unaffected.
我在这方面不太了解，但我读了这个 Gojko Adzic 最近发表的博客文章，我认为这是相关的，内容是关于 DTO 不一定是一个好主意以及在不同的层上重复域模型是可以的以免违反DRY。
I'm not too knowledgeable in this area, but I read this blog post by Gojko Adzic recently which I think is relevant, about how DTOs aren't necessarily a good idea and that it's Ok to have your domain model repeated on separate tiers so as not to violate DRY.