我经常在研究一个想法时阅读各种博客和SO问题，并且通常会得到一个很好的参考和解决方案列表，但这次我很难看到它...这可能是一个很长的帖子但是我想提供尽可能多的细节:)）
我非常喜欢DDD，并且在有意义的地方应用它，我开始将它用于我正在进行的项目，但是我对事件采购的阅读越多，我就越想采用这种模式，我的理由：
我们有一个集中式服务器和多个断开连接的客户端，断开连接的客户端包含来自服务器的数据子集，客户端都可以有相交的数据集。
任何客户都可以修改数据并在他们选择的时间同步更改。因此，我们有一个位于服务器前面的“网关”，用于管理数据的同步。
对于某些聚合，如果一个客户端更改了另一个客户端与之交叉的数据，则他们必须能够查看更改的历史记录。
这对我来说非常适合ES，我可以将DTO发送到服务器，服务器可以检查版本匹配，合并更改，并创建适当的事件。如果版本不匹配，请获取自上一个客户端版本以来的事件列表，并在可能的情况下自动解决任何冲突。
实体的逻辑结构如下：
D有一个E和F的列表
当执行某些命令时，D需要知道B中的信息，反之亦然。
现在，这个逻辑必须在客户端实现，但它是否也需要在“网关”中实现？
由于网关接收的任务仅基于CRUD，并且具有RESTful API。
客户端是移动应用程序，网站和桌面应用程序 - 每个客户端都将本地存储视为可以从服务器重建的缓存（查询端和纯DDD，客户端目前不使用事件源，这不能强制执行因为有些人可能是第三方）。
网关就像TFS，Git，SVN等，所以它是否也应关注实际应用的域逻辑？或者他们是2个不同的BC？我正在尝试保留SRP，但如果发送了DTO，应该首先在服务器上运行应用程序的域逻辑，然后再运行同步逻辑？
这么多问题，我在努力寻找在类似场景中描述CQRS / ES / DDD的资源？
（我可以提供更多细节，但我漫不经心！） 其他人将如何设计这种情况？