From http://martinfowler.com/bliki/BoundedContext.html

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

DDD is about designing software based on models of the underlying domain. A model acts as a UbiquitousLanguage to help communication between software developers and domain experts. It also acts as the conceptual foundation for the design of the software itself - how it's broken down into objects or functions. To be effective, a model needs to unified - that is to be internally consistent so that there are no contradictions within it.

As you try to model a larger domain, it gets progressively harder to build a single unified model. Different groups of people will use subtly different vocabularies in different parts of a large organization. The precision of modeling rapidly runs into this, often to leading to a lot of confusion. Typically this confusion focuses on the central concepts of the domain. Early in my career I worked with a electricity utility - here the word "meter" meant subtly different things to different parts of the organization: was it the connection between the grid and a location, the grid and a customer, the physical meter itself (which could be replaced if faulty). These subtle polysemes could be smoothed over in conversation but not in the precise world of computers. Time and time again I see this confusion recur with polysemes like "Customer" and "Product".

In those younger days we were advised to build a unified model of the entire business, but DDD recognizes that we've learned that "total unification of the domain model for a large system will not be feasible or cost-effective" [1]. So instead DDD divides up a large system into Bounded Contexts, each of which can have a unified model - essentially a way of structuringMultipleCanonicalModels.

Bounded Contexts have both unrelated concepts (such as a support ticket only existing in a customer support context) but also share concepts (such as products and customers). Different contexts may have completely different models of common concepts with mechanisms to map between these polysemic concepts for integration. Several DDD patterns explore alternative relationships between contexts.

Various factors draw boundaries between contexts. Usually the dominant one is human culture, since models act as Ubiquitous Language, you need a different model when the language changes. You also find multiple contexts within the same domain context, such as the separation between in-memory and relational database models in a single application. This boundary is set by the different way we represent models.

DDD's strategic design goes on to describe a variety of ways that you have relationships between Bounded Contexts. It's usually worthwhile to depict these using a context map.

Further Reading

The canonical source for DDD is Eric Evans's book. It isn't the easiest read in the software literature, but it's one of those books that amply repays a substantial investment. Bounded Context opens part IV (Strategic Design).

Vaughn Vernon's Implementing Domain-Driven Design focuses on strategic design from the outset. Chapter 2 talks in detail about how a domain is divided into Bounded Contexts and Chapter 3 is the best source on drawing context maps.

I love software books that are both old and still-relevant. One of my favorite such books is William Kent's Data and Reality. I still remember his short description of the polyseme of Oil Wells.

Eric Evans describes how an explicit use of a bounded context can allow teams to graft new functionality in legacy systems using a bubble context. The example illustrates how related Bounded Contexts have similar yet distinct models and how you can map between them.

Notes

1: Eric Evans in Domain-Driven Design

Bounded Context的更多相关文章

  1. 区分DDD中的Domain, Subdomain, Bounded Context, Problem/Solution Space

    区分DDD中的Domain, Subdomain, Bounded Context, Problem/Solution Space 译自: Domain, Subdomain, Bounded Con ...

  2. DDD:Strategic Domain Driven Design with Context Mapping

    Introduction Many approaches to object oriented modeling tend not to scale well when the application ...

  3. 浅谈我对DDD领域驱动设计的理解

    从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品 ...

  4. DDD 领域驱动设计-商品建模之路

    最近在做电商业务中,有关商品业务改版的一些东西,后端的架构设计采用现在很流行的微服务,有关微服务的简单概念: 微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成.系统中的各个微服务可被独 ...

  5. DDD实践切入点(二)

    最近发现下面关于上下文的理解有些问题,不太好改,暂时先不改了 承前:大型系统的支撑,应用系统开发思想的变迁,DDD实践切入点(一) 从大比例结构入手已经开始了系统的建设,大家都知道需求是会不断变化不断 ...

  6. DDD实践切入点(一)

    前两篇:大型系统的支撑,应用系统开发思想的变迁 之前大致说了使用DDD的前期准备,现在可以真正开始实践了,以我刚刚结束的一个简单的经典DDD方式的项目为例子,当然由于比较简单,所以很多时候会脱离它来介 ...

  7. IDDD 实现领域驱动设计-理解限界上下文

    上一篇:<IDDD 实现领域驱动设计-理解领域和子域> <实现领域驱动设计>前两章内容,基本上读完了,和<领域驱动设计>不同的是,它把很多的概念都放在前面进行讲述了 ...

  8. CloudNotes之领域建模篇:领域模型简介

    CloudNotes领域模型还是相对简单的,并不一定需要采用面向领域驱动的设计方法来解决CloudNotes的领域问题.但出于以下几个方面的原因,我还是采用了面向领域驱动的方式来开发CloudNote ...

  9. 微服务(Microservices)—Martin Fowler【翻译】

    本文转载自:http://www.cnblogs.com/liuning8023/p/4493156.html -------------------------------------------- ...

随机推荐

  1. UVA 10652 Board Wrapping(二维凸包)

    传送门 刘汝佳<算法竞赛入门经典>P272例题6包装木板 题意:有n块矩形木板,你的任务是用一个面积尽量小的凸多边形把它们抱起来,并计算出木板占整个包装面积的百分比. 输入:t组数据,每组 ...

  2. 今天写页面,将.net也使用了语义法规来判断。做法来源是.net ado.net的类型判断 Infertype。一样的原理

    做了一个封装,使页面更容易维护一些.主要是两个方法,如下所示: private void BindModule(Action<Repeater, string> bindSingRpt)  ...

  3. AngularJS 作用域与数据绑定机制

    AngularJS 简介 AngularJS 是由 Google 发起的一款开源的前端 MVC 脚本框架,既适合做普通 WEB 应用也可以做 SPA(单页面应用,所有的用户操作都在一个页面中完成).与 ...

  4. 10个简化Web开发者工作的HTML5开发工具

    HTML5的到来,改变了设计和开发的工作,完全改变了以前的开发方式. HTML5进行本身就是一个很简单,很快捷的开发技术并且带给开发人员很多不同的工具和功能,使他们的工作变得更加Cool.它的功能非常 ...

  5. 转:python安装pycrypto

    from: http://ljhzzyx.blog.163.com/blog/static/3838031220136592824697/   在windows下用一下开源工具就是悲催,如题pytho ...

  6. linux资源限制函数getrlimit,setrlimit(转载)【转】

    转自:http://blog.csdn.net/stormkey/article/details/5890512 版权声明:本文为博主原创文章,未经博主允许不得转载. getrlimit,setrli ...

  7. XML技术总结之XDocument 和XmlDocument

    引言 虽然现在Json在我们的数据交换中越来越成熟,但XML格式的数据还有很重要的地位. C#中对XML的处理也不断优化,那么我们如何选择XML的这几款处理类 XmlReader,XDocument ...

  8. Mysql优化的方法

    一.表的优化: 1: 定长与变长分离 如 time.手机号等,每一单元值占的字节是固定的. 核心且常用字段,宜建成定长,放在一张表,查询速度会很快 而varchar, text,blob,这种变长字段 ...

  9. Redis数据类型、两种模型、事务、内部命令

    1.redis数据类型 a.字符串,使用场景:常规key-value缓存应用 set name lixiang get name append name 123 # 字符串追加 mset key va ...

  10. [BZOJ2460][BJOI2011]元素(线性基)

    2460: [BeiJing2011]元素 Time Limit: 20 Sec  Memory Limit: 128 MBSubmit: 2195  Solved: 1119[Submit][Sta ...