域驱动设计 – 当仍有可能发生无用事件或撤消时,您是否立即将事件应用于域模型？

概述我看到的每个事件采购示例都是针对网络的.它似乎特别适用于MVC架构,其中客户端上的视图不运行域代码并且交互性有限.我不完全确定如何推断到富桌面应用程序,用户可能正在编辑列表或执行其他长时间运行的任务. 域模型是持久性不可知和表示不可知的,只能通过将域事件应用于聚合根来进行突变.我的具体问题是,当用户进行未提交的更改时,演示文稿代码是否会改变域模型？ >如果演示代码不改变域模型,那么如何强制执行域逻 我看到的每个事件采购示例都是针对网络的.它似乎特别适用于MVC架构,其中客户端上的视图不运行域代码并且交互性有限.我不完全确定如何推断到富桌面应用程序,用户可能正在编辑列表或执行其他长时间运行的任务.

域模型是持久性不可知和表示不可知的,只能通过将域事件应用于聚合根来进行突变.我的具体问题是,当用户进行未提交的更改时,演示文稿代码是否会改变域模型？

>如果演示代码不改变域模型,那么如何强制执行域逻辑？在用户编辑时,将即时域验证和域计算冒泡到演示模型会很不错.否则,您必须在视图模型中复制非平凡逻辑.
>如果演示代码确实改变了域模型,那么如何实现撤销？没有域取消删除事件,因为撤消的概念仅存在于未通信的编辑会话中,并且我不愿意添加每个事件的撤消版本.更糟糕的是,我需要能够无序地撤消事件.您是否只删除了该事件并重放每次撤消的所有内容？ (例如,如果文本字段返回其先前状态,也会发生撤消.)
>如果演示代码确实改变了域模型,那么持久化用户执行的每个事件或者只是将用户的活动压缩到可能的最简单事件集更好吗？举一个简单的例子,想象一下将注释字段改为和
在保存之前.你真的坚持每个中间人吗？
在同一编辑期间,CommentChangedEvent在同一个字段上
会议？或者对于更复杂的示例,用户将是
更改参数,运行优化计算,调整
参数,重新运行计算等,直到该用户为止
对最近的结果感到满意并承诺更改.一世
不要以为有人会考虑所有中间事件的价值
存储.你会如何保持这种浓缩？

有复杂的协作域逻辑,这让我觉得DDD / ES是可行的方法.我需要一张富有的客户端视图模型和域模型交互的图片,我希望简洁和优雅.

解决方法 我没有看到桌面DDD应用程序与MVC应用程序有很大不同,你基本上可以拥有相同的层,除了它们大部分不是网络分离的.

CQRS / ES应用程序最适合task-based UI,您可以在其中发出反映用户意图的命令.但是,通过任务,我们并不是指用户可以在屏幕上执行的每个 *** 作,它必须在域中具有意义和目的.正如您在3中正确指出的那样,无需将每个微修改建模为完整的DDD命令和相关事件.它可能会污染您的事件流.

所以你基本上有两个层次：

UI级别 *** 作

这些可以完全在表示层中进行管理.它们堆叠起来最终映射到单个命令,但您可以非常轻松地单独撤消它们.没有什么可以阻止您将它们建模为例如封装closures for do and undo的微事件.我从来没有在任何用户界面中看到过“樱桃可读”的内容,也没有真正看到这一点,但只要行为是可交换的(它们的效果不依赖于执行顺序),这应该是可行的并且用户可理解.

域级别任务

由命令和相应事件表示的粗粒度活动.如果你需要撤消这些,我宁愿在事件流中添加一个新的回滚事件,而不是尝试删除现有事件(“不要改变过去”).

在UI中反映域不变量和计算

这是您必须正确区分两种类型的任务的地方,因为除了一些基本验证(必填字段,字符串和数字格式等)之外,UI *** 作通常不会更新屏幕上的任何内容.发出命令,另一方面,将导致模型的刷新视图,但您可能必须通过某个确认按钮来实现 *** 作.

如果您的UI主要是向用户显示计算的数字和投影,这可能是一个问题.您可以将计算放在UI调用的单独服务中,然后在用户保存时发出包含所有更新计算值的修改命令.或者,您只需提交一个包含您更改的参数的命令,并让域调用相同的计算服务.两者实际上更接近CRUD,并可能通过IMO导致贫血领域模型.

总结

以上是内存溢出为你收集整理的域驱动设计 – 当仍有可能发生无用事件或撤消时,您是否立即将事件应用于域模型？全部内容，希望文章能够帮你解决域驱动设计 – 当仍有可能发生无用事件或撤消时,您是否立即将事件应用于域模型？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。