domain-driven-design - DDD 限界上下文针对同一概念的不同模型

Question

我有一个包含多个子域的 ERP 项目。它没有使用 CQRS 或领域事件。

我有两个子域；客户关系管理和会计。客户概念需要在两个子域中以不同方式建模。 CRM 需要知道公司的规模(员 worker 数)而不是税号。会计需要知道税号而不是税号。两个子域都需要公司名称。

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

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

Answer 1

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

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

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

如果另一方面，他们都从其他事物中了解到它，那么也许他们都会对其他事物的事件使用react。

如果您不想使用事件，可以直接调用，从 CRM 上下文到会计上下文。虽然知道这会随着应用程序的增长而受到更多限制，但如果您再次拥有一个简单的域，那没问题。

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