虽然我熟悉《四人帮》中描述的设计模式，但在企业层面上，会有很多我从未听说过的模式。希望有一个能激发我解决工作中面临的问题的方法：
我有三个应用程序正在协同工作。让我们称它们为 ApplA、ApplB 和 ApplC。它们共享一些域模型，例如类MyEntity。
public class MyEntity
{
public Guid ID {get;set;}
public string Name {get;set;}
//other properties
}
用户可以使用 ApplA 重命名此类对象。发生这种情况时，应在 ApplB和 ApplC 中执行操作。这是通过使用队列(Kafka，但队列系统的选择可能无关紧要(来实现的。按照快乐的路径，两个应用程序从队列中获取消息，并执行各自的操作。
但是，替代路径是 ApplB 或 ApplC 在处理来自队列的消息时失败。假设应用程序 ApplB 失败，则 ApplC 不应执行其操作，或者撤消其操作。对于如何解决这些问题，是否有任何模式/指导。
编辑：在上面的文本中，我谈到了重命名MyEntity，但我看到该声明如何被误解。通过重命名，我不打算更改类名，而是重命名类型MyEntity的对象(请注意属性 Name(。因此，为了给出一个更好、更明确的例子，请考虑使用Person实体的多个应用程序。
public class Person
{
public Guid ID {get;set;}
public string FirstName {get;set;}
public string LastName {get;set;}
//other properties
}
如果一个人改变姓氏(当荷兰的女性结婚时，她们使用丈夫的姓氏仍然是常见的做法(，所有相关应用程序都必须执行一些业务逻辑。请注意，这不仅仅是更新一个数据库的问题，还必须执行更多的业务逻辑。现在，如果其中一个应用程序无法执行其操作而其他应用程序成功，那么哪种模式/编程实践正在解决此类问题？
既然您提到领域模型是方法论的一部分，我将提出一个在 DDD(域驱动设计(上下文中上下文映射的模式答案。对于不同的上下文(应用程序(，域模型可能相似，也可能不相似。您可以在链接上阅读有关每种模式的更多信息，但它们是：
- 共享内核
- 客户/供应商开发团队
- 墨守成规
- 防腐层
- 分道扬镳
如果我没记错的话，Apache Kafka 是一种"反腐败层"。
域模式超出了GoF(软件类模式(的范围，因为建模处于不同的级别。
关于您的"重命名"问题，当您不提供有关重命名的类是什么以及其他应用程序对名称的假设的更多详细信息时，很难说。在本应在大学工作的应用程序中将"学生"的域类重命名为"Fish"没有任何意义。这真的取决于很多时候的具体情况。