DDD之限界上下文

限界上下文是一个显示的边界，领域模型便存在于这个边界之内。领域模型把通用语言表达成软件模型，在实现DDD的时候，我们致力于将限界上下文中领域模型所用到的每一个术语都进行限界划分。这种限界主要是语言层面上的上下文边界，也是实现DDD的关键。在边界内，通用语言中的所有术语和词组都有特定的含义，而模型需要准确地反映通用语言。需要注意的是，一个限界上下文不一定包含在一个子域中，但这是有可能的。

也就是有了限界上下文，一些语言才有了特定的含义。一个上下文中不只包含领域模型，虽然限界上下文是用来封装通用语言和领域对象的，但同时它也包含了那些为领域模型提供交互手段和辅助功能的内容。限界上下文应该足够大，以能够表达它所对应的整套通用语言。

一个限界上下文定义好之后，并不是一成不变的，随着业务发展是需要不断迭代的。我们要不断的增加一些概念进来，也要剔除一些不属于范围内的概念。在每个迭代中，我们都应该对之前的假设提出挑战，这使得我们向模型中添加或删除一些概念，或者改变概念的行为和写作方式等。在使用DDD原则时，我们会认真地思考应该添加哪些概念，又应该删除哪些概念。使用限界上下文和上下文映射图这样的工具可以帮助我们分析出哪些概念的确应该属于该范围。

限界上下文的大小

影响限界上下文大小的两大因素：

• 错误的采用架构来指导开发，而不是通用语言。

• 根据开发任务的分配来拆分限界上下文

将限界上下文看成一个技术组件/项目工程并无大碍，但是需要明确的是技术组件/项目工程并不能定义限界上下文。在使用Intellij IDE的情况下，很多是由一个限界上下文就是一个项目，当使用Visual Studio，同一个解决方案(项目)拆分成多个子项目也是合理的。在使用Java时，顶层包名通常标识限界上下文中顶层模块的名字。在敏捷开发的驱动下，一个限界上下文对应一个项目往往是不太可能的，建议是一个团队，一个限界上下文。而子域和限界上下文最好是一对一的关系。

上下文映射图

上下文映射图其实就是体现出不同限界上下文之间的上下游依赖关系和集成方式的图形，可以是任何形式的图形。上下文映射图主要是帮助我们从解决方案空间的角度看待问题。上下文映射图并不是一个企业架构，也不是系统拓扑图，它不需要太过细致的划分。但是，它可以用于高层次的架构分析，指出诸如集成瓶颈之类的架构不足。上下文映射图展现了一种组织动态能力（organizational dynamic）,它可以帮助我们识别出一些有碍项目进度的管理问题。

上下文映射图更多的时候是为了能够完成上下文自治，减少过多的强依赖。上下文自治是为了实现上下文更加干净、整洁，提高质量。

集成限界上下文

限界上下文有多种集成方式，行业通用的有以下三种：

• 通过RPC远程调用API

• 消息队列（发布-订阅机制）

• 在HTTP协议下使用RESTful方式（开放主机服务）

• 共享文件或者数据库等（过时）

所谓的集成实际上就是我们常说的通信方式，需要注意的是，每一种集成方式都有本身的优缺点和最佳适用场景。通常在项目开发中也会引入一些适配器或者防腐层来控制过度集成造成的复杂问题。