DDD中BoundedContext视为限制上下文更好
“We often fall into the trap of thinking of a boundary as something that separates one thing from another. We should rather think of a boundary as something that constitutes that which is bounded. This shift will help us to see the boundary as something enabling”—Paul Cilliers
“我们经常陷入这样一个陷阱：将边界这个概念看成是用来是将一件事与另一件事化分开，（比如划清界线，划分边界，分割线，边界线，领域边界）
但是，我们更应该将边界视为有限构成事物的一个事物。这种转变将帮助我们将边界视为一种赋能”——Paul Cilliers
banq：边界也是一个事物，这个事物是一种构建事物，如同设计模式中的工厂模式或builder构建者模式，工厂对象或builder对象是一个专门的用来构建的对象事物，这种构建的能力是有限的，不是无限的，有限是指空间或时间上的有限，有界，有起点和终点，有生命周期，有作用域的。
因此，bounded context的bounded如果翻译成“有限”这个词可能更好，“界限”或“有界”都是一种静态边界线的意思，而“有限”则包含动态上构建时是有限的意思，不是源源不断的构建，源源不断无限的构建是流stream。
综合理解
DDD中战略基础概念：
- Domain = Boundary ：领域 等于边界
- BoundedContext @ UL ：BC来自于或位于无所不在通用语言UL
- Aggregates *emerges* from BC：聚合是从BC中"涌现"出来的一种关系体。
领域的边界是固定的，能比较长的生命周期内存在，静态的，类似全局静态变量；而上下文的边界则不是静止的，可能会动态模糊泄露，生命周期比较短和模糊，甚至一段时间内相互穿插，类似作用域概念。
BC上下文只有当被制成构建时才体现边界、有限或界限，正如黑人 白人出生时是有皮肤的区别界线，但是出生以后的边界就可能模糊了，人人平等了，都公平参与竞争，英雄就不问出处了，但是出处出身是有区别的，是我们设计时关注点。
BC上下文的出处是来自通用语言UL的，从UL中有限地发现构建制成了一些上下文，这样的上下文诞生之初肯定是有边界的，但是，我们不能认为上下文就永远被这个边界限制住了，随着时间发展，上下文之间的边界可能会模糊，但只要构建时是有限地构建制成了即可。
将关注点从永恒边界转移到BC诞生之初，这样做的好处是：
可以将BC就可以看成一种赋能，来自通用语言的赋能，
BC就在DDD战略设计和战术设计之间架起了一座桥梁，
赋能者（通用语言）可以通过BC赋能给战术设计中的聚合、实体、值对象等概念，也就是说，我们可以从UL中挖掘或通过暗喻、隐喻等方式赋能战术设计概念，典型案例见：通过语言的暗喻发现隐藏的DDD模型 - verraes
“限制”比“有限”更好
补充更正：Bounded Context翻译成“限制上下文”更准确，“限制”表示有限地制成了某个上下文。
之前认为“有限”比“有界”或“界限”更恰当，因为表示赋能的能力边界，“有限”这个词语并没有体现“制成或构建”这个创建动作的含义，例如工厂模式的“工厂”包含了一种“生产”这个动作含义，因此，“限制”比“有限”更恰当。
构造与解构
当我们从构建这个角度看问题时，DDD可以划分两个大部分：
- DDD战略设计=构造
- DDD战术设计=解构
两者之间的桥梁是BC，战略设计是从现实业务中构造一个领域模型，这种附带有BC的领域模型进入战术阶段被却分解成如聚合或实体或值对象等。
但是现实中很容易发生将两个阶段割裂的情况，这也是过去OOA和OOD两阶段割裂的弊病。
如果将BC看成一种赋能，这样对聚合或实体的任何结构修改都必须考虑到BC，这样才能将业务逻辑和代码紧紧融合浑然一体，正如将算法逻辑与代码融合一样。
(业务领域Domain =>赋能或驱动=> 软件设计Design) = DDD
