当考虑 DDD 时，只将一些数据传输到 UI 有意义吗？
假设我有一个模型考试。将有一个包含问题和答案的 Question 对象的集合，以及每个学生回答内容的集合。
我认为应用程序层只向表示层提供创建 UI 所需的位是可以的。换句话说，当学生回答问题时，应用层不会将其他学生呈现给表示层。
当数据返回到应用层时也是同样的想法。问题无法更改，因此我们仅将学生的答案发回以附加到领域模型。
恕我直言，这是根据 E. Evans 对应用程序层的描述：定义软件应该执行的工作并指导表达域对象解决问题。
Say I have a model Exam. There will be a collection of Question objects containing questions and answers, and a collection of what each student have answered.
I think it is ok for the application layer to give the presentation layer only the bits it need to create the UI. In other words when students are answering questions, the application layer does not present the other students to the presentation layer.
Same idea when the data goes back to the application layer. Questions cannot change, so we send only the students answer back to be attached to the domain model.
IMHO this is according to E. Evans description of the application layer: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，这确实有道理。不仅如此，在我看来，在大多数情况下，这应该是首选架构。问题是 DDD 非常适合管理复杂性，同时保持聚合和有界上下文（当某些内容发生更改时发生的事情）内的一致性。并且读取（显示）数据时不应该有任何变化，因此在这部分您无法从 DDD 获得帮助。此外，如果您使用域对象向 UI 层提供数据，您最终会为用户界面而不是业务域定制域，并且这些是不同的上下文。
实际上，有基于这些事实的完整架构，CQRS 就是其中之一。 CQRS 有一个保留两组数据存储的好主意 - 一组针对域模型量身定制，另一组明确准备读取数据以呈现在 UI 上（例如）。
您可能还对关于存储库模式的这篇博文感兴趣作者 Szymon Pobiega - 它也遵循分离写入（域）和读取的思想（查询）方面。
Yes, it does make sense. Not only that, in most scenarios this should be the go-to architecture, in my opinion. The thing is DDD is great in managing complexity while keeping consistency within aggregates and bounded context - the things that occur when something gets changed. And there shouldn't be any change while reading (displaying) the data, so you get no help from DDD on this part. Moreover, if you use your domain object for providing data to your UI layer, you end up tailoring domain for user interface instead of business domain, and these are different contexts.
Actually there are entire architectures basing on that facts, CQRS being one of them. CQRS has this great idea of keeping two sets of data stores - one tailored to domain model, the other explicitly prepared for reading the data to present on UI (for example).
You might also be interested in this blog post on the repository pattern by Szymon Pobiega - it also follows the idea of separating the write (domain) and read (queries) side.