Merge pull request #7 from macdao/master

fix missing space issues

docs/ch10.md

@@ -460,7 +460,7 @@ Decompose design elements (operations, interfaces, classes, and AGGREGATES) into
 
 The goal is a simple set of interfaces that combine logically to make sensible statements in the UBIQUITOUS LANGUAGE, and without the distraction and maintenance burden of irrelevant options. This is typically an outcome of refactoring: it’s hard to produce up front. But it may never emerge from technically oriented refactoring; it emerges from refactoring toward deeper insight.
 
-> 我们的目标是得到一组可以在逻辑上组合起来的简单接口，使我们可以用 UBIQUITOUSLANGUAGE 进行合理的表述，并且使那些无关的选项不会分散我们的注意力，也不增加维护负担。但这通常是通过重构才能得到的结果，很难在前期就实现。而且如果仅仅是从技术角度进行重构，可能永远也不会出现这种结果；只有通过重构得到更深层的理解，才能实现这样的目标。
+> 我们的目标是得到一组可以在逻辑上组合起来的简单接口，使我们可以用 UBIQUITOUS LANGUAGE 进行合理的表述，并且使那些无关的选项不会分散我们的注意力，也不增加维护负担。但这通常是通过重构才能得到的结果，很难在前期就实现。而且如果仅仅是从技术角度进行重构，可能永远也不会出现这种结果；只有通过重构得到更深层的理解，才能实现这样的目标。
 
 Even when the design follows CONCEPTUAL CONTOURS, there will need to be modifications and refactoring. When successive refactoring tends to be localized, not shaking multiple broad concepts of the model, it is an indicator of model fit. Encountering a requirement that forces extensive changes in the breakdown of the objects and methods is a message: Our understanding of the domain needs refinement. It presents an opportunity to deepen the model and make the design more supple.
 
@@ -988,7 +988,7 @@ This final feature is not usually needed and can be difficult to implement, but
 
 Consider again the chemical warehouse packer from the example on page 235. Recall that each Chemical had a Container Specification, and the Packer SERVICE guaranteed that all these would be satisfied when Drums are assigned to Containers. All is well... until someone changes the regulations.
 
-> 再次考虑一下前面的化学仓库打包程序的例子。每个 Chemical 都有一个 ContainerSpecification，而且 Packer SERVICE 确保当把 Drum 分配到 Container 中时，所有这些 Container Specification 都被满足，一切都没有问题……直到有人改变了规则。
+> 再次考虑一下前面的化学仓库打包程序的例子。每个 Chemical 都有一个 Container Specification，而且 Packer SERVICE 确保当把 Drum 分配到 Container 中时，所有这些 Container Specification 都被满足，一切都没有问题……直到有人改变了规则。
 
 Every few months a new set of rules is issued, and our users would like to be able to produce a list of the chemical types that now have more stringent requirements.
 
@@ -1090,7 +1090,7 @@ A AND B AND C → A AND B
 
 So if the Composite Specification is able to collect all the leaf SPECIFICATIONS that are “ANDed” together, then all we have to do is check that the subsuming SPECIFICATION has all the leaves that the subsumed one has, and maybe some extra ones as well—its leaves are a superset of the other SPEC’s set of leaves.
 
-> 这样，如果 Composite Specification 能够把所有由“AND”连接起来的叶节点（leaf）SPECIFICATION 收集到一起，那么我们要做的事情只是检查包容规格（subsumingSPECIFICATION）是否含有被包容规格的所有叶节点（而且它可能还包含更多的叶节点）——它的叶节点集合是另一个 SPECIFICATION 的叶节点集合的超集。
+> 这样，如果 Composite Specification 能够把所有由“AND”连接起来的叶节点（leaf）SPECIFICATION 收集到一起，那么我们要做的事情只是检查包容规格（subsuming SPECIFICATION）是否含有被包容规格的所有叶节点（而且它可能还包含更多的叶节点）——它的叶节点集合是另一个 SPECIFICATION 的叶节点集合的超集。
 
 ```java
 public boolean subsumes(Specification other) {
@@ -1274,7 +1274,7 @@ There are enough pointers now to start probing for that new model. The Share obj
 
 The Share Pie represents the total distribution of a specific Loan. It is an ENTITY whose identity is local within the AGGREGATE of the Loan. The actual distribution calculations can be delegated to the Share Pie.
 
-> Share Pie 表示了一个特定的 Loan 的总体分布。它是一个 ENTITY，其标识位于 LoanAGGREGATE 的内部。实际的分布计算可以被委托给 Share Pie。
+> Share Pie 表示了一个特定的 Loan 的总体分布。它是一个 ENTITY，其标识位于 Loan AGGREGATE 的内部。实际的分布计算可以被委托给 Share Pie。
 
 <Figures figure="10-19"></Figures>
 
@@ -1297,7 +1297,7 @@ public class Loan {
 
 The Loan is simplified, and the Share calculations are centralized in a VALUE OBJECT focused on that responsibility. Still, the calculations haven’t really become more versatile or easier to use.
 
-> 这样 Loan 就被简化了，而且 Share 计算也被集中到了一个 VALUE OBJECT 中（这个 VALUEOBJECT 只负责这个计算）。但是，这个计算并没有真正变得通用和易用。
+> 这样 Loan 就被简化了，而且 Share 计算也被集中到了一个 VALUE OBJECT 中（这个 VALUE OBJECT 只负责这个计算）。但是，这个计算并没有真正变得通用和易用。
 
 Share Pie Becomes a VALUE OBJECT: Cascade of Insights
 

docs/ch12.md

@@ -60,7 +60,7 @@ Example: Route-Finding Policies
 
 A Route Specification is being passed to a Routing Service, whose job is to construct a detailed Itinerary that satisfies the SPECIFICATION. This SERVICE is an optimization engine that can be tuned to find either the fastest route or the cheapest one.
 
-> 我们把一个 Route Specification（路线规格）传递给 Routing Service（路线服务）, RoutingService 的职责是构造一个满足 SPECIFICATION 的详细的 Itinerary。这个 SERVICE 是一个优化引擎，可以通过调节它来查找最快的路线或最便宜的路线。
+> 我们把一个 Route Specification（路线规格）传递给 Routing Service（路线服务）, Routing Service 的职责是构造一个满足 SPECIFICATION 的详细的 Itinerary。这个 SERVICE 是一个优化引擎，可以通过调节它来查找最快的路线或最便宜的路线。
 
 <Figures figure="12-1">A SERVICE interface with options will need conditional logic.</Figures>
 
@@ -84,11 +84,11 @@ This design has the advantages that motivate the STRATEGY pattern in Design Patt
 
 A fundamentally important rule in the domain, the basis of choosing one Leg over another when building an Itinerary, is now explicit and distinct. It conveys the knowledge that a specific attribute (potentially derived) of an individual leg, boiled down to a single number, is the basis for routing. This makes possible a simple statement in the language of the domain that defines the Routing Service’s behavior: The Routing Service chooses an Itinerary with a minimum total magnitude of the Legs based on the chosen STRATEGY.
 
-> 现在，领域中的一个至关重要的规则明确地显示出来了，也就是在构建 Itinerary 时用于选择 Leg 的基本规则。它传达了这样一个知识：路线选择的基础是航段的一个特定属性（有可能是派生属性），这个属性最后可归结为一个数字。这样，我们就能够通过领域语言很简单地定义 RoutingService 的行为：Routing Service 根据所选的 STRATEGY 来选择 Leg 总规模最小的 Itinerary。
+> 现在，领域中的一个至关重要的规则明确地显示出来了，也就是在构建 Itinerary 时用于选择 Leg 的基本规则。它传达了这样一个知识：路线选择的基础是航段的一个特定属性（有可能是派生属性），这个属性最后可归结为一个数字。这样，我们就能够通过领域语言很简单地定义 Routing Service 的行为：Routing Service 根据所选的 STRATEGY 来选择 Leg 总规模最小的 Itinerary。
 
 Note: This discussion implies that the Routing Service is actually evaluating Legs as it searches for an Itinerary. This approach is conceptually straightforward, and it could make a reasonable prototype implementation, but it is probably unacceptably inefficient. This application will be taken up again in Chapter 14, “Maintaining Model Integrity,” where the same interface will be used with a completely different implementation of the Routing Service.
 
-> 说明：以上讨论暗示了一件事。Routing Service 在查找 Itinerary 时实际上会计算 Leg 的规模。这种方法在概念上比较直接，而且可以生成一个合理的原型实现，但它的效率可能令人无法接受。第 14 章会再次讨论这个应用程序，其将使用相同的接口，但采用完全不同的 RoutingService 实现。
+> 说明：以上讨论暗示了一件事。Routing Service 在查找 Itinerary 时实际上会计算 Leg 的规模。这种方法在概念上比较直接，而且可以生成一个合理的原型实现，但它的效率可能令人无法接受。第 14 章会再次讨论这个应用程序，其将使用相同的接口，但采用完全不同的 Routing Service 实现。
 
 ---
 
@@ -206,7 +206,7 @@ Because I referred to the FLYWEIGHT pattern earlier (in Chapter 5), you might ha
 
 When a limited set of VALUE OBJECTS is used many times (as in the example of electrical outlets in a house plan), it may make sense to implement them as FLYWEIGHTS. This is an implementation option available for VALUE OBJECTS and not for ENTITIES. Contrast this with COMPOSITE, in which conceptual objects are composed of other conceptual objects. In that case, the pattern applies to both model and implementation, which is an essential trait of a domain pattern.
 
-> 当一个 VALUE OBJECT 集合（其中的值对象数目有限）被多次使用的时候（如房屋规划中电源插座的例子），那么把它们实现为 FLYWEIGHT 可能是有意义的。这是一个适用于 VALUEOBJECT（但不适用于 ENTITY）的实现选择。COMPOSITE 模式与它的不同之处在于，组合模式的概念对象是由其他概念对象组成的。这使得组合模式既适用于模型，也适用于实现，这是领域模式的一个基本特征。
+> 当一个 VALUE OBJECT 集合（其中的值对象数目有限）被多次使用的时候（如房屋规划中电源插座的例子），那么把它们实现为 FLYWEIGHT 可能是有意义的。这是一个适用于 VALUE OBJECT（但不适用于 ENTITY）的实现选择。COMPOSITE 模式与它的不同之处在于，组合模式的概念对象是由其他概念对象组成的。这使得组合模式既适用于模型，也适用于实现，这是领域模式的一个基本特征。
 
 I’m not going to try to compile a list of the design patterns that can be used as domain patterns. Although I can’t think of an example of using an interpreter as a domain pattern, I’m not prepared to say that there is no conception of any domain that would fit. The only requirement is that the pattern should say something about the conceptual domain, not just be a technical solution to a technical problem.