Design patterns 同步共享域模型的设计模式

虽然我熟悉四人帮中描述的设计模式，但在企业层面上，会有很多我从未听说过的模式。希望有一种方法能激发我解决工作中面临的问题：

我有三个应用程序在一起工作。让我们称他们为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不应执行其操作，或者撤销其操作。是否有关于如何解决此类问题的模式/指南

Edit：在上面的文本中，我谈到了重命名

MyEntity

，但我知道这句话可能会被误解。通过重命名，我并不打算更改类名，而是重命名类型为

MyEntity

的对象（注意属性名）。因此，为了给出一个更好和更为明确的例子，考虑多个应用程序使用<代码>人>代码>实体。

 public class Person
 {
    public Guid ID {get;set;}
    public string FirstName {get;set;}
    public string LastName {get;set;}
    //other properties 
 }

---

如果一个人改变了姓氏（荷兰的女性结婚时，仍然习惯于使用丈夫的姓氏），所有相关的应用程序都必须执行一些业务逻辑。注意，不仅仅是更新一个数据库，还需要执行更多的业务逻辑。现在，如果其中一个应用程序在执行其操作时失败，而其他应用程序成功了，那么什么样的模式/编程实践解决了这样的问题呢？

既然您提到了领域模型作为方法论的一部分，我将提出以下问题的答案。对于不同的上下文（应用程序），域模型可能相似，也可能不相似。您可以在链接上阅读有关每个图案的更多信息，但以下是：

• 共享内核
• 客户/供应商开发团队
• 墨守成规的
• 反腐败层
• 分道扬镳

如果我没有弄错的话，ApacheKafka是一种“反腐败层”

领域模式超出了GoF（软件类模式）的范围，因为建模处于不同的级别

---

关于你的“重命名”问题，很难说你什么时候不提供更多关于被重命名的类以及其他应用程序对名称的假设的细节。在本应在大学工作的应用程序中，将域类“Student”重命名为“Fish”是没有任何意义的。这实际上取决于很多细节。

设计模式适用于同一应用程序中的代码。没有什么是跨应用程序的。您对这三个应用程序工作方式的描述类似于责任链模式，但同样，这仅适用于同一应用程序中的代码。考虑把这三个应用程序合并在一起。这三个应用程序中的两个是我们不直接开发自己的独立产品，我们只是创建了插件。因此，合并应用程序不是一个选项。什么插件？在我看来，你的应用程序正在调用其他两个应用程序？如果是这样，那么您可以在应用程序中使用责任链模式来控制如何调用其他两个应用程序。@SimonAx如果有人更改了姓名，而某个应用程序无法自我更新，您需要一个容错模式来处理此问题。罗伯特·汉默有一本关于它们的书。有些模式甚至涉及人工干预，例如，操作员可以手动更正失败应用程序上的重命名，或从其他应用程序中撤消重命名。还有自动化的解决方案。