使用域驱动设计来设计“客户帐户资料”

Question

我正在按照域驱动设计创建微服务，它将负责在电子商务环境中处理客户帐户信息。例如：客户有一个收货地址清单，一个帐单地址清单，一个先前的订单清单，卡等等。

当前，当我要定义要涉及的一个或多个聚合时，我是一个阶段。

如该图所示，客户帐户是我的客户帐户微服务中的根对象。我不确定使用这种方法是否正确。任何指导将不胜感激，我的目标是为客户帐户信息定义一种域驱动设计方法，该方法基本上需要能够存储地址，订单以及也许很多其他与客户相关的项目。这是拥有可以容纳我需要的所有内容的CustomerAccount聚合模型的正确方法吗？

Answer 1

通常，通过代表业务或组织的某些领域（从行为的角度来看），可以最好地为您的子域提供服务。我看到您有一个结帐服务，这很有意义。

我认为客户服务是一种选择，取决于您的情况。客户帐户微服务确实有意义，但我想问题是您是否应该在客户服务中包含订单实体信息。

我至少要有一个客户汇总根和一个单独的订单汇总根。 （鉴于它们可以独立发展和改变）。下一步将是为订单分离新服务。给定的客户帐户和订单具有彼此独立的一些明确职责。分离服务可能很难知道何时何地。

功能之外的另一个原因是安全性和访问模式。您是否要从订单中隔离客户信息（客户信息是否要求更高的安全性边界？）。所访问的订单和客户资料是否相同（资料信息是一项更繁忙的服务，因此需要更多资源吗？）。与往常一样，我认为这是灵活性，控制性和复杂性之间的平衡。

所以我不确定是对还是错。希望对您有所帮助。