php - 如何在不同的限界上下文中将学说实体拆分为更多领域实体？

Question

我正在 DDD ( Domain-driven design) 领域尝试我的第一步。我喜欢这个明智的规则，你应该将你的实体分成许多更小的、特定于上下文的实体(例如 User 实体几乎在每个非 ddd 或设计不佳的应用程序中都会过度增长)。但是，关于如何使用 Doctrine 在 php 中(有效地)执行此操作的常见选项是什么？

假设我有两个限界上下文:Store 和 Invoicing

他们每个人都有两个领域实体:对于 Store BC，它是 FirstTimeCustomer 和 RecurrentCustomer对于 Invoicing BC，它是 VatCustomer 和 NonVatCustomer

现在，在我的基础架构层中，我希望将它们全部保存在同一个(至少是基表)表中，以便能够通过通用 UserId (Uuid) 引用它们。对我来说，问题是如何做到这一点，这样我就可以在我的存储库实现中利用学说自动映射的优势。

我阅读了单表继承或 Class Table Inheritance这可能是解决方案，但是:

我需要能够使用相同 Uuid 的 User，因为它在每个上下文中都是不同的类型。

我需要能够在 $storeCustomerRepository->find(1) 上返回一些 AbstractStoreCustomer 又名 FirstTimeCustomer 或 RecurrentCustomer； 在商店 BC 中。

并在 $invoicingCustomerRepository->find(1); 上返回一些 AbstractInvoicingCustomer 又名 VatCustomer 或 NonVatCustomer在开票 BC 中。

但似乎我被迫在这里选择我想要绑定(bind)实体的特定标识的 BC。所以它在 DDD 的上下文中对我来说根本没有意义。

我还阅读了 Mapped Superclasses ，这看起来也是一个选项，但是:

This means that One-To-Many associations are not possible on a mapped superclass at all.

我需要 Customer 与订单相关，这应该在两个实体中都可用(也可能不希望它可用是一些新类型的 User新 BC 中的实体)。

我得出结论，我应该怀疑我遗漏了什么，是吗？我应该如何实现将上帝实体分解成更小的上下文特定实体？

Answer 1

我将从一些通用规则开始。在考虑 DDD 时，您必须拒绝任何关于持久性(表和主键等)的想法。您必须像将它们存储在文件中一样设计聚合根和实体。当你设计模型时，如果你想到表或 ORM，你就没有做 DDD；退后一步，重新开始。

如我所见，您通过按限界上下文拆分模型开始了 OK。如果你不按 BC 拆分它们，你最终会得到试图包含所有行为的巨大模型，然后持久性将影响性能，因为在 DDD 中，聚合在一个事务中持久化。另一件事，尽量避免继承并使用组合。

话虽如此，让我们谈谈您的业务。在 Authentication BC 中，Users 可以使用一些凭据进行身份验证。在 Store BC 中有 Customers 购买东西。在 Invoice BC 中，还有 Customers，但模型不同(如果需要，可以是不同的类)。在 Shipping BC 中也有 Customers 但同样是不同的模型。这些 Customer 模型沿 BC 共享一些属性，例如 name 和 id。因此，您使用 id 来识别现实生活中的人，但根据上下文使用不同的模型来封装他们的行为。

我认为你不应该有一个 AbstractStoreCustomer，你应该只有 Customer 并尝试在抽象类/接口(interface)中隔离它们的区别，比如 BuyingHistoryProfile 有 2 个实现 FirstTimeCustomer 和 RecurrentCustomer。此类应该只包含有关购买配置文件的行为，它应该被 Store BC 中的每个 Customer 引用。类似地，尝试在 Invoicing BC 中提取一个类用于价格计算。

现在我们已经创建了模型，我们可以考虑持久性了。为每个有界上下文创建一个 Customer 表，其中包含共享属性(name 和 id)和特定属性(buyingHistoryProfile 用于 Store BC，priceCalculationStrategy 用于 Invoicing BC 等)。

如果您想知道存在一定程度的数据重复，那么您是对的，但这是正常的，有必要将模型解耦。当 Authentication BC 中的 User 更改其名称时，此重复数据会同步:您会立即更新所有其他模型。从这个角度看，Invoice和StoreBC是下游，它们使用的数据来自AuthenticationBC；何时启动更新取决于您的业务。

作为事件驱动架构的粉丝，我建议您看一下 CQRS(甚至事件溯源)。我认为这些架构非常适合这个应用程序。 CQRS 可以使您的模型清洁 10 倍，我根据我的经验告诉您。使用事件溯源，您很可能甚至不必使用 ORM。您可以在读取端使用 ORM，如果您真的喜欢它们或者您不能离开它们。我个人不喜欢(也不使用)ORM。