DDD中的编舞传奇-整合事件链？
我目前正在研究传奇模式。大多数示例似乎都集中在编排传奇上，其中我们有一个中央传奇执行协调器服务，用于分派和接收消息/事件。不幸的是，关于如何实现编舞传奇的信息似乎缺乏一点。
在域驱动设计中，我们有多个有界上下文，理想情况下，每个有界上下文都是一个自包含的微服务。如果微服务A想与另一个微服务B通信，我们使用集成事件。集成事件是使用某种异步通信来发布和订阅的--RabbitMQ、Azure服务总线。
假设我们想要开始一些传奇，例如，我们必须在订单服务和客户服务上运行事务--服务之间到底是如何通信的？这只是常规的集成事件还是完全不同的事情？
-
null
共有1个答案
我认为，如果您出于正确的原因选择分布式事务，那么使用编排而不是编排是有意义的。例如，如果您需要省去通常较高的实现中央编排的工作，因为在事务完成之前，您不需要知道事务处于什么状态。或者因为您知道事务工作流的顺序是稳定的，不太可能改变，这也是编排的好的一面。但是如果顺序频繁变化，这将是编排的一个缺点，因为在这种情况下，您需要调整所有的微服务...
因此，您需要了解这两种方法的优缺点。
如果您选择编舞是出于正确的原因，我会说我在您的考虑中遗漏了补偿逻辑。如果信用被保留了，但订单在订单服务中失败了，怎么办？在这种情况下，赔偿事件也需要考虑。
-
null
-
我对DDD和CQRS的概念是新的，无法找到一个最终的解决方案如何以一种干净的方式上传图像或文件。 我有三个想法来解决这个问题，但我对它们不是很满意。 方式1: 1。在单个请求中发布所有数据，包括图像（多部分） 2。创建，它返回. 3。之后，创建并将与构造函数中的根数据一起传递。就CQRS而言，一个用户交互应该只有一个命令。 方法2: 1。将图像发送到分离endpoint，创建临时文件并返回id或文
-
本文向大家介绍iOS 事件传递的完整过程?相关面试题，主要包含被问及iOS 事件传递的完整过程?时的应答技巧和注意事项，需要的朋友参考一下 先将事件对象由上往下传递(由父控件传递给子控件)，找到最合适的控件来处理这个事件。 调用最合适控件的touches….方法 如果调用了[super touches….];就会将事件顺着响应者链条往上传递，传递给上一个响应者 接着就会调用上一个响应者的touch
-
在CQRS ES和DDD中，聚合中的小读模型从其他聚合或有界上下文中获取数据是件好事吗？ 例如，在订单验证（订单聚合）中，有一个业务规则，该规则仅在未标记客户时验证订单。标志信息通过同步域事件放入读取模型（特定于聚合）。 你怎么看？
-
这是最奇怪的错误，我甚至不知道从哪里开始理解错在哪里。 S3一直工作得很好，直到突然有一天（昨天）它奇怪地编码任何上传给奇怪字符的文本文件。每当一个文本文件中有`、`、Ω或任何其他UTF-8可比字符，但没有英文字符时，该文本文件就会被弄乱。我尝试过使用各种客户端以及AWS的web界面上传。上传很顺利，然后我下载文件，它搞砸了。我试着把它下载到我的Mac上，我试着把它下载到带有Linux的覆盆子上。
-
我是事件采购的新手，但对于我们当前的项目，我认为这是一个非常有前途的选择，主要是因为审计跟踪。 有一件事我不是100%满意，那就是缺乏跨聚合的超越。请考虑以下问题： 我有一个订单，它在不同的机器上处理，在不同的车站。我们有集装箱，工人们把订单放进去，然后把它从一台机器运到另一台机器。 必须通过容器（具有唯一的条形码id）进行跟踪，订单本身无法识别。问题是：容器是重用的，需要锁定，因此没有工作人员可