使用领域驱动设计中的 Bounded Context 概念分解大领域模型

Juelie Lerman 近期在 MSDN 杂志中解释说，开发者可以应用领域驱动设计（DDD）中的Bounded Context 概念将一个大模型分解为几个较小的模型，每一个模型对应 Entity Framework （EF）中的 Database Context（DbContext 类）。

按照 Julie（她从 2003 年以来就是 Microsoft MVP ，也是一位.NET 平台的顾问及导师）的说法，把一个将大量的类放在一个上下文中的独立模型分解为多个较小的模型是有好处的。Bounded Context 创建的模型较小，而且内聚性更高，同时维持了模型之间的边界，Julie 的文章就是基于这一事实的。但她也指出，比起使用 EF DbContext，DDD 中的 Bounded Context 是一个更大的概念，因此她称自己的实现方式为“受限的”或“专注的”DbContext。

通过分离属于不同上下文的类（例如：将针对顾客的类和针对订单及配送的类分离，并把这些类放入独立的 DbContext 中），Julie 将一个包含了整个应用程序所有类的大型上下文分解为更小而且更专注的上下文，而在其下运行的大型数据模型及数据库表依然不变。
如果在某个上下文中，某个类的所有属性并非全部必需，那就可以创建一个更小而且更专注的类，它涵盖了原始类的某些部分，并间接地涵盖了底层数据库表的某些部分 [z2] ，这是通过在数据库中使用视图来实现的。使用这些类的一个限制是：如果有某些不允许为空的表字段不在这些类的控制之下，那就不能够使用这些类完成数据库的插入操作，否则在进行插入操作时，DbContext 会抛出异常。

使用“Code First”，以自动生成所有数据库表的方式创建数据库需要更多工作，包括需要一个独立的“全局模型（über-model）”，以及一个包含所有类的 DbContext，这个完整的 DbContext 将用于初始化数据库。

对于以这种方式应用 Bounded Context 的做法， DDD 原书的作者 Eric Evans 在一条推特中给出了正面的反馈，不过也有人心存疑虑并给出了备选方案。有反馈意见认为这种做法违背了Bounded Context 的概念，并援引了DDD 社区的定义：

“应该[z3] 显式地定义某个模型所应用的上下文。还应该在团队组织、应用中特定部分的使用以及像代码库和数据库模式等物理表现等方面显式地设定边界。要保持边界中模型的严格一致，而不要受外界问题的影响与干扰。”

Entity Framework 是 Microsoft 在.NET 平台上推出的对象关系映射工具。

查看英文原文： Using the Domain Driven Design Bounded Context Concept to Shrink a Large Domain Model

感谢臧秀涛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。