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

转自：http://www.infoq.com/cn/news/2013/03/ddd-bounded-context-large-domain

作者 Jan Stenberg 译者 邵思华 发布于 2013年3月4日

领域 

企业架构, 

架构 & 设计, 

语言 & 开发 

主题 

领域建模 , 

模型驱动架构 , 

架构 , 

领域驱动设计 , 

实体框架

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