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

DDD Bounded Contexts Different Models For The Same Concept

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

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

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

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

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

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

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

如果另一方面,他们都从其他事物中了解到它,那么也许他们都会对其他事物的事件做出反应。

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

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