DDD-映射上下文

Many models at play

1. Domain Driven Design puts a great emphasis in maintaining the conceptual integrity of the model of your application. This is achieved by a combination of several factors:

• an agile process that emphasizes frequent feedback from users and domain experts,
• the availability of real domain experts and a creative collaboration with them,
• a single and shared version of the model (in the application and test code) precisely defined in terms of the Ubiquitous Language, and
• an open and transparent environment that promotes learning and exploration.

注释：领域模型对于DDD非常重要，它有很多因素决定（及时的反馈，随时可以交流的领域专家，共同的语言，开放和透明的环境）

 

Enter Bounded Contexts

2。 In Domain Driven Design, a Context is defined as:         "The setting in which a word or a statement appears that determines its meaning" which might sound rather vague（模糊的） at first read. It doesn't say much about expected size, shape or other characteristics of a context. We'll eventually discover that this definition is rather precise, describing exactly what a context is, but to get a glimpse of that we probably need a few concrete examples.

 

Example 1: Same term, different meaning

Let's start with a simple example where the ambiguity might happen at the terminology level. Some words have different meaning depending on the context they’re used in.

Let's suppose we're working on a web-based Personal Finance Management Application (PFM) . We'll probably use this application to manage the banking accounts, stocks, and savings, to track the budget and expenses, and so on.

In our application, the domain term Account might refer to different concepts. Talking about banking, an account is some kind of a logical "container for money"; we'll then expect the corresponding class to have attributes such as balance, account number, and so on. But, in the context of web applications, the term account has a very different meaning, related to authentication and user credentials. The corresponding model, as shown in Figure 2, will then be something completely different.

http://www.infoq.com/articles/ddd-contextmapping

注释："Account"在银行的上下文就是用来放钱的东西, 但是对于网站来说，它就是管理权限的。

 

This is probably the simplest case of ambiguity we can run into when modeling our applications: same term, with two different context dependent meanings. This issue is often resolved by partitioning the name space by adding some prefix to the class name (be it the name itself or part of the package). But on a conceptual level, we must be aware that we have two different contexts in play, sometimes they're different enough to prevent developers from doing mistakes, but sometimes the difference might be subtle.

注释：我们可以通过命名空间或者加一些前缀改成不同的名字。但是我们要知道我们在不同的上下文里。

 

Unfortunately, working at a class name level might not always be a viable(可行的) solution: in the domain of Banking, the term Banking Account might already exist, with a different meaning, or the domain expert would insist that Account is the right term. Resist the temptation to invent a specific trade-off term, or to introduce a translation offset from domain expert terms to code. You're facing two separate contexts here.

注释：如果只是停留在名字上做文章，会造成很多麻烦，上下文可以解决这个问题。