您如何计划并将应用程序划分为有限的上下文？一方面，将所有这些解耦都非常方便，但另一方面，过多的粒度会导致非常繁琐的开发。这条细线在哪里？在设计有界上下文和上下文映射时，您考虑了哪些因素？他们是技术性的，战略性的吗？
在很多例子中，您将电子商务应用视为一组有界的背景：目录，购物，发票，交付等。
来自哪里？
答案 0 :(得分：2)
技术，绝对不是......
你听说过Event Storming吗？我认为这是找到自己边界的好方法......
有限的上下文是关于语言，不是技术或架构思考，而是关于您的域和域专家使用的词的更多信息：Greg Young explain-it well in the beginning of this talk
当你为你的领域模型建模时，你必须定义你的界限（对于电子商务，产品不同的概念在不同的上下文中具有相同的属性：目录，购物......关于客户的同样的事情......和你不必为每个上下文使用相同的实体，所以每个上下文都有其特定的Ubiguitous语言），迭代地思考这个活动（有时出现有界上下文并且不是首先清晰可见）
答案 1 :(得分：1)
只要您使用相同的单词来定义不同的概念，您就会遇到两个有界的上下文。
假设有一个处理电影租赁的应用程序 如果您的团队（业务/开发人员）谈论“用户”以身份和访问权限来定义用户，而“用户”也就 Renters 而言，那么您会有两个有限的背景：
有界语境是所选择的普遍存在的语言的反映。
答案 2 :(得分：1)
对于从头开始建模域，我认为从一个有界上下文和一个模块开始是一个很好的决定。在一个模块中，概念开始发生冲突或看起来很奇怪，是时候将一些概念分成不同的模块（或者在模块之间重新组织）。 将模块分成不同的有界上下文的方法相同。