rad*_*rad 1 domain-driven-design aggregate bounded-contexts
在我目前的项目(电子商务网站)中,我们有不同的有界背景,例如:结账过程中的结算,交付或付款.
除此之外,根据客户的购买要求,结账流程也会有所不同.因此,根据购物车的内容,结帐过程中的步骤数可能会有所不同,或者我们不会/将要求她提供某些信息.
那么,是否应该为每种不同类型的结账流程创建不同的有界上下文？
例如,订单聚合根将根据结帐流程EticketsOrder而不同(在此上下文中我们不需要递送地址,因此我们不会向用户询问)Ticket BillingAddress
ClothesOrder(在这种情况下,我们需要一个送货地址,在结账过程中还有一个额外的步骤来获得这个)衣服BillingAddress DeliveryAddress
这种分离意味着创建两个不同的域实体,即使它们具有相似的属性.
模拟这类问题的最佳方法是什么？如何找到上下文边界？
有界语境主要是语言边界.蓝皮书的引用(突出显示关键部分):
有界背景界定了特定模型的适用性,以便团队成员对必须一致的内容以及与其他上下文的关系有清晰和共同的理解.在该CONTEXT中,努力使模型在逻辑上统一,但不要担心超出这些范围的适用性.在其他背景中,其他模型适用于术语,概念和规则以及UBIQUITOUS LANGUAGE方言的差异.
要问的问题是,创建的不同类型的订单是完全不同的聚合,还是所有订单聚合都具有不同的值.无论如何创建订单,是否需要考虑整体订单？我已经构建并使用电子商务系统,其中不同类型的订单都被建模为相同聚合的实例,只是具有不同的设置并且没有语言问题.另一方面,您域中的订单可能不同,足以保证不同的上下文.
我经常从功能凝聚力的角度考虑BC边界.如果将订单分成两个BC,它们之间会有很高的耦合吗？如果是这样,那可能表明他们应该合并为一个BC.另一方面,如果BC与之交互的唯一地方是出于报告目的,则无需将它们组合在一起.