【问题标题】：Design a "Customer Account Profile" using Domain Driven Design使用领域驱动设计设计“客户帐户资料”
【发布时间】：2020-04-18 13:19:34
【问题描述】：
我希望按照领域驱动设计创建一个微服务，该微服务将负责在电子商务环境中处理客户帐户信息。
例如：客户有一个送货地址列表、一个帐单地址列表、一个以前的订单列表、卡片等等。
目前，我正处于我想定义将涉及的聚合/聚合的阶段。
如图所示，客户帐户是我的客户帐户微服务中的根对象。我不确定我在使用这种方法时是否走在正确的轨道上。任何指导将不胜感激，我的目标是为客户帐户信息定义域驱动设计方法，该方法基本上需要能够存储地址、订单以及许多其他与客户相关的项目。这是拥有一个包含我需要的所有内容的 CustomerAccount 聚合模型的正确方法吗？
【问题讨论】：
标签：
architecture
domain-driven-design
e-commerce
cqrs
software-design
【解决方案1】：
您的子域通常通过代表您的业务或组织的某些领域（从行为角度）得到最好的服务。我看到你有一个结帐服务，这是有道理的。
我认为客户服务是一种取决于您的情况的选择。客户帐户微服务确实有意义，但我想问题是您是否应该在客户服务中拥有您的订单实体信息。
我至少会有一个客户聚合根和一个单独的订单聚合根。 （鉴于它们都可以独立进化和改变）。更进一步的做法是为 Orders 分离一个新服务。给定客户账户和订单有一些明确的职责，相互独立。分离服务可能很难知道何时以及为什么。
功能之外的另一个原因是安全性和访问模式。您是否想将客户信息与订单隔离（客户信息是否需要更高的安全边界？）。访问的订单和客户资料是否相同（资料信息是否是一项更繁忙的服务，因此需要更多资源？）。与往常一样，我认为这是灵活性、控制力和复杂性之间的平衡。
所以我不确定这是对还是错。我希望这会有所帮助。