Domain driven design 同一概念的不同模型

我有一个ERP项目与多个子域。它不使用CQR或域事件

我有两个子域；客户关系管理和会计。客户概念需要在两个子领域中进行不同的建模。CRM需要知道公司的规模（员工人数），但不需要知道税号。会计需要知道税号，但不需要知道规模。两个子域都需要公司名称

我正在考虑将CRM客户和会计客户都建模为实体。但是，每当CRM用户创建新客户时，也需要创建一个Accounting customer实例。如果报表需要来自这两个子域的信息，那么查询将比包含所有信息的单个实体更复杂

---

这是路吗？有更好的办法吗？在不使用域事件的情况下拥有多个子域有意义吗？

您确定需要DDD吗？这个用例看起来很简单，也许你忽略了所有其他的复杂性，但是从你所询问的信息来看，一个简单的CRUD应用程序就可以了。以数据为中心的应用程序，如报告，不需要DDD。当必须严格修改数据以保持一致性时，需要DDD

如果您确定您确实需要DDD，那么您需要理解模型的要点是保护不受域不变量的影响。您说CRM客户必须始终有一个同等的会计客户。今天企业如何处理这一问题？会计如何了解CRM客户？会计如何知道他们谈论的是与CRM相同的客户？不管他们目前在做什么，这是你应该尝试建模的

举个例子，如果他们在现实生活中只是让对方知道。您可以让您的CRM上下文发布新的客户事件，您的会计上下文可以通过为其创建会计客户来对其作出反应

如果从另一方面来说，他们都是从其他事情中了解到这一点的，那么他们可能都会对另一件事情做出反应

如果您不想使用事件，可以直接从CRM上下文调用会计上下文。虽然我们知道，随着应用程序的增长，这将变得更加受限，但如果你又有一个简单的域，那就没问题了

---

此外，查询数据与修改数据不同。查询不应使用域模型实体和值对象。它可以，但不应该受到它的约束。这是因为查询是一个只读操作。只有当您要更改数据时，才需要将数据放入域模型中。

实际域更大。只是举了一个例子，因为在大多数关于跨域使用的概念的讨论中，一个域拥有一个实体中的所有信息，而其他域只是将该实体的一部分复制到一个值对象中。我只是想知道如果两个域需要关于同一事物的完全不同的信息怎么办。你把它放在哪里，怎么同步。看现实生活的部分是我所缺少的。在我看来，这总是一个技术问题。从普遍存在的语言角度来看，这似乎是正确的。CRM客户和会计客户显然不一样。这两个BC之间是否能够在没有CQR或应用程序分离的情况下保持一致，完全取决于您的上下文-用户数量、开发团队规模、可部署性需求等。从维护的角度来看，域事件更实际（反向依赖，添加订户更容易），它们为异步打开了大门，允许更好地表达随着时间的推移所发生的事情，在开发团队内部以及与领域专家之间进行更好的沟通。您确定您正确识别了上下文边界吗？看看