fix more missing space issues

docs/ch10.md

@@ -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>
 

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 实现。
 
 ---
 

docs/ch14.md

@@ -20,7 +20,7 @@ If only they had been more aware of this reality, they could have consciously de
 
 What did they do once they knew about the problem? They created separate Customer Charge and Supplier Charge classes and defined each according to the needs of the corresponding team. The immediate problem having been solved, they went back to doing things just as before. Oh well.
 
-> 他们在知道了问题所在之后采取了什么措施呢？他们创建了两个不同的类：CustomerCharge（客户收费）类和 Supplier Charge（供应商收费）类。并根据各自的需求定义了每个类。解决了眼前这个问题之后，他们又按以前的方式开始工作了。
+> 他们在知道了问题所在之后采取了什么措施呢？他们创建了两个不同的类：Customer Charge（客户收费）类和 Supplier Charge（供应商收费）类。并根据各自的需求定义了每个类。解决了眼前这个问题之后，他们又按以前的方式开始工作了。
 
 Although we seldom think about it explicitly, the most fundamental requirement of a model is that it be internally consistent; that its terms always have the same meaning, and that it contain no contradictory rules. The internal consistency of a model, such that each term is unambiguous and no rules contradict, is called unification. A model is meaningless unless it is logically consistent. In an ideal world, we would have a single model spanning the whole domain of the enterprise. This model would be unified, without any contradictory or overlapping definitions of terms. Every logical statement about the domain would be consistent.
 

docs/ch15.md

@@ -890,7 +890,7 @@ The other change is more pragmatic. In the refactored model, the Customer Agreem
 
 And what about pulling Customer out, anyway? The focus is on fulfilling the Customer’s requirements, so at first Customer seems to belong in the CORE. Yet the interactions during delivery do not usually need to involve the Customer class now that the Customer Agreement is available directly. And the basic model of a Customer is pretty generic.
 
-> 那么到底是否应该把 Customer 提取出来呢？我们的关注点是要满足 Customer 的需求，因此最初看上去 Customer 应该属于 CORE。然而，由于运输期间的交互现在可以直接访问 CustomerAgreement 了，因此就不再需要 Customer 类。这样 Customer 的基本模型就非常通用了。
+> 那么到底是否应该把 Customer 提取出来呢？我们的关注点是要满足 Customer 的需求，因此最初看上去 Customer 应该属于 CORE。然而，由于运输期间的交互现在可以直接访问 Customer Agreement 了，因此就不再需要 Customer 类。这样 Customer 的基本模型就非常通用了。
 
 A strong argument could be made for Leg to remain in the CORE. I tend to be minimalist in the CORE, and the Leg has tighter cohesion with Transport Schedule, Routing Service, and Location, none of which needed to be in the CORE. But if a lot of the stories I wanted to tell about this model involved Legs, I’d move it into the Delivery package and suffer the awkwardness of its separation from those other classes.
 

docs/ch16.md

@@ -384,15 +384,15 @@ Once a large-scale structure has been adopted, subsequent modeling and design de
 
 There are many possible approaches. In the absence of a large-scale structure, one appealing design would be to give the responsibility of incorporating these routing rules to the object that owns the Route Specification and the Hazardous Material (HazMat) code—namely the Cargo.
 
-> 有很多可行的方法。在未使用大比例结构时，一种吸引人的设计方法是让拥有 RouteSpecification 和 Hazardous Material（HazMat）代码的对象负责把这些航线规则加进来，这个对象就是 Cargo。
+> 有很多可行的方法。在未使用大比例结构时，一种吸引人的设计方法是让拥有 Route Specification 和 Hazardous Material（HazMat）代码的对象负责把这些航线规则加进来，这个对象就是 Cargo。
 
 <Figures figure="16-9">A possible design for routing hazardous cargo</Figures>
 
 <Figures figure="16-10"></Figures>
 
 The trouble is, this design doesn’t fit the large-scale structure. The HazMat Route Policy Service is not the problem; it fits neatly into the responsibility of the Decision Support layer. The problem is the dependency of Cargo (an Operational object) on HazMat Route Policy Service (a Decision Support object). As long as the project is committed to these layers, this model cannot be allowed. It would confuse developers who expected the structure to be followed.
 
-> 问题是这种设计并不适合大比例结构。HazMat Route Policy Service 并没有问题，它非常适合承担决策支持层的职责。问题在于 Cargo（一个作业层对象）对 HazMat Route PolicyService（一个决策支持层对象）的依赖上。只要项目还采用目前的分层，就不能使用这个模型，因为开发人员会认为设计将遵循分层结构，而这种依赖会使开发人员感到糊涂。
+> 问题是这种设计并不适合大比例结构。HazMat Route Policy Service 并没有问题，它非常适合承担决策支持层的职责。问题在于 Cargo（一个作业层对象）对 HazMat Route Policy Service（一个决策支持层对象）的依赖上。只要项目还采用目前的分层，就不能使用这个模型，因为开发人员会认为设计将遵循分层结构，而这种依赖会使开发人员感到糊涂。
 
 There are always many design possibilities, and we’ll just have to choose another one—one that follows the rules of the large-scale structure. The HazMat Route Policy Service is all right, but we need to move the responsibility for using the policy. Let’s try giving the Router the responsibility for collecting appropriate policies before searching for a route. This means changing the Router interface to include objects that policies might depend on. Here is a possible design.
 

docs/ch2.md

@@ -221,7 +221,7 @@ User: Yes, but it’s extra work for us to make all the supporting plans for a n
 
 Developer: Oh. Then we’ll have to add some functionality to the Route Specification. Then, whenever you change anything in the Spec, we’ll see if the Itinerary still satisfies the Specification. If it doesn’t, we’ll have the Routing Service regenerate the Itinerary.
 
-> 开发人员：哦。那么需要在 Route Specification 添加一些功能。这样，当更改 RouteSpecification 中的属性时，查看 Itinerary 是否仍满足 Specification。如果不满足，则需要由 Routing Service 重新生成 Itinerary。
+> 开发人员：哦。那么需要在 Route Specification 添加一些功能。这样，当更改 Route Specification 中的属性时，查看 Itinerary 是否仍满足 Specification。如果不满足，则需要由 Routing Service 重新生成 Itinerary。
 
 User: You won’t have to worry about this on origin or destination, since the Itinerary would always change then.