您将如何处理具有大部分相同业务逻辑但在域语言和实体属性方面略有不同的域。这些差异因“地区”而异。
一个虚构的例子是用于管理住宅房地产的房地产系统。州/省之间使用的语言可能略有不同,在某些州,有关房地产的属性可能更详细。每个州/省都会有一个办公室来管理该“地区”的房地产。
你会为每个州/省创建一个单独的限界上下文吗?那么可能会有 50 多个限界上下文?
你会创建一个单一的限界上下文,并通过对象继承或组合来处理语言和数据的变化吗?
您将如何处理具有大部分相同业务逻辑但在域语言和实体属性方面略有不同的域。这些差异因“地区”而异。
一个虚构的例子是用于管理住宅房地产的房地产系统。州/省之间使用的语言可能略有不同,在某些州,有关房地产的属性可能更详细。每个州/省都会有一个办公室来管理该“地区”的房地产。
你会为每个州/省创建一个单独的限界上下文吗?那么可能会有 50 多个限界上下文?
你会创建一个单一的限界上下文,并通过对象继承或组合来处理语言和数据的变化吗?
我联系了DDD 领域的领导者之一Vaughn Vernon,我想我会分享他的回应(由我总结)。
根据我提供的有限信息和示例,他提出了以下几点:
首先让我说我不认为这里有灵丹妙药。与往常一样,这一切都取决于不同的因素。这样我的反应不是一个具体的想法,而是你和你的团队在做出决定的过程中可以考虑的一组考虑因素。
如果我被要求定义一个有界上下文,我会说它是setting
aword
有某个meaning
or的地方connotation
。如果我们可以同意上述陈述之一,那么人们会立即想为每个区域或setting
. 也就是说,如果您从所有这些上下文中获得的好处有助于代码库的可理解性。但是,如果您创建的上下文非常薄,或者您为拥有所有这些上下文付出了沉重的技术维护成本,我强烈建议您不要使用多个上下文。
我不确定,但我觉得在您的情况下,在每种情况下word
都会有相同meaning
的情况,只是在每种情况下word
使用的会有所不同。而通常word
在不同的上下文中使用的相同具有不同的含义。
我希望这一切都是有道理的,它可以帮助你找出你的问题。