使用领域驱动设计中的Bounded Context概念分解大领域模型
2013-03-06 17:02
351 查看
转自: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
作者 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
相关文章推荐
- 使用领域驱动设计中的Bounded Context概念分解大领域模型
- 一般什么时候使用类图,使用到什么程度、领域模型概念、 顺序图说明、协助图、状态图、系统的顺序(用例驱动)、需求分析
- 领域模型驱动设计(Domain Driven Design)入门概述
- C#进阶系列——DDD领域驱动设计初探(五):AutoMapper使用
- 领域驱动设计学习-让领域模型发挥作用
- DDD(领域驱动设计)应对具体业务场景,如何聚焦 Domain Model(领域模型)?
- DDD 领域驱动设计-领域模型中的用户设计
- 浅谈领域模型驱动中表的设计方法
- 领域驱动设计学习-让领域模型发挥作用
- DDD 领域驱动设计-Value Object(值对象)如何使用 EF 进行正确映射
- 数据仓库的模型设计 A. 数据建模方法论 数据仓库模型设计遵循“自顶向下、逐步求精”的设计原则。 模型设计分为三个阶段: 1,概念模型 对业务的范围和使用,从高度上进行抽象概括,也就是划分主题域。 一
- 领域驱动设计(3)模型驱动设计
- 领域驱动设计之领域模型
- Entity Framework模型在领域驱动设计界定上下文中的应用
- 使用模型驱动开发和基于模式的工程来设计 SOA之第 4 部分
- 领域驱动设计之领域模型
- 领域驱动设计之领域模型
- 领域驱动设计和贫血、失血、充血模型
- 使用UML的基础平台的设计之二(概念模型)
- 领域驱动设计系列(3)有选择性的使用领域驱动设计