【发布时间】：2014-08-06 06:51:34
【问题描述】：
您如何规划应用程序并将其划分为有界上下文？一方面，所有这些解耦非常方便，但另一方面，过多的粒度会导致非常麻烦的开发。这条细线在哪里？在设计有界上下文和上下文映射时，您会考虑哪些因素？它们是技术性的还是战略性的？
在很多示例中，您将电子商务应用程序视为一组有界上下文：目录、购物、发票、交付等。
那些来自哪里？
【问题讨论】：
【发布时间】：2014-08-06 06:51:34
【问题描述】：
技术性的，绝对不是……
您听说过Event Storming 吗？我认为这是找到界限的好方法...
限界上下文是关于语言的，它不是技术或架构思考，而是更多关于你的领域和你的领域专家使用的词：Greg Young explain-it well in the beginning of this talk
当您为您的领域模型建模时，您必须定义您的边界（对于电子商务，产品不是在不同上下文中具有相同属性的同一个概念：目录、购物......关于客户也是一样......您不必为每个上下文使用相同的实体，因此每个上下文都有其特定的 Ubiguitous 语言），迭代地考虑这个活动（有时会出现有界上下文并且首先不清晰可见）
【讨论】：
一旦您使用两个相同的词来定义不同的概念，您就会面临两个有界上下文。
假设一个应用程序处理电影出租。
如果您的团队（业务/开发人员）谈论“用户”以根据身份和访问权限来定义用户，而“用户”也以租户来定义，那么您会有两个有界上下文：
- IdentityAndAccessContext（管理身份验证、角色等。技术）
- MovieRentalContext（不知道用户，但知道租户）
有界上下文是所选通用语言的反映。
【讨论】：
对于从头开始建模域，我认为从一个有界上下文和一个模块开始是一个不错的决定。比起概念开始冲突或保留在一个模块中看起来很奇怪，是时候将一些概念分成不同的模块（或在模块之间重新组织）。 将模块分成不同的有界上下文的相同方法。
【讨论】：