Seventeen. Bringing the Strategy Together
The preceding three chapters presented many principles and techniques for domain-driven strategic design. In a large, complex system, you may need to bring several of them to bear on the same design. How does a large-scale structure coexist with a CONTEXT MAP? Where do the building blocks fit in? What do you do first? Second? Third? How do you go about devising your strategy?
前面 3 章给出了战略层面上应用领域驱动设计的很多原则和技术。在一个大的、复杂的系统中，可能需要在一个设计中综合运用几种策略。那么，大型结构如何与 CONTEXT MAP 共存？应该把构造块放到哪里？第一步先做什么？第二步和第三步呢？如何设计你的战略？
The three basic principles of strategic design (context, distillation, and large-scale structure) are not substitutes for each other; they are complementary and interact in many ways. For example, a large-scale structure can exist within one BOUNDED CONTEXT, or it can cut across many of them and organize the CONTEXT MAP.
战略设计的 3 个基本原则（上下文、精炼和大型结构）并不是可以互相代替的，而是互为补充，并且以多种方式进行互动。例如，一种大型结构可以存在于一个 BOUNDED CONTEXT 中，也可以跨越多个 BOUNDED CONTEXT 存在，并用于组织 CONTEXT MAP。
The previous examples of RESPONSIBILITY LAYERS were confined to one BOUNDED CONTEXT. This is the easiest way to explain the idea, and it’s a common use of the pattern. In such a simple scenario, the meanings of layer names are restricted to that CONTEXT, as are the names of model elements or subsystem interfaces that exist within that CONTEXT.
前面的 RESPONSIBILITY LAYER 的例子被限定在一个 BOUNDED CONTEXT 中。这是解释这一思想的最简单的方法，也是该模式的一般用法。在这样的简单场景中，层名称的含义仅用于该 CONTEXT，该 CONTEXT 中的模型元素或子系统接口的名称也是如此。
Structuring a model within a single BOUNDED CONTEXT
Such a local structure can be useful in a very complicated but unified model, raising the complexity ceiling on how much can be maintained in a single BOUNDED CONTEXT.
这样的局部结构在一个非常复杂但统一的模型中是很有用的，它使系统所能承受的复杂度上限提高了，进而使得在一个 BOUNDED CONTEXT 中可以维护更多的对象。
But on many projects, the greater challenge is to understand how disparate parts fit together. They may be partitioned into separate CONTEXTS, but what part does each play in the whole integrated system and how do the parts relate to each other? Then the large-scale structure can be used to organize the CONTEXT MAP. In this case, the terminology of the structure applies to the whole project (or at least some clearly bounded part of it).
但是在很多项目中，更大的挑战是理解怎样使各个不同的部分构成一个整体，如图 17-3 所示。这些部分可能被划分到不同的 BOUNDED CONTEXT 中，但是各个部分在整个集成系统中的作用是什么，它们之间又是如何互相关联的？理解了这些问题之后就可以用大型结构来组织 CONTEXT MAP。在这种情况下，结构的术语适用于整个项目（或至少是项目中某个明确限定的部分）。
Structure imposed on the relationships of components of distinct BOUNDED CONTEXTS
Suppose you want to adopt RESPONSIBILITY LAYERS, but you have a legacy system whose organization is inconsistent with your desired large-scale structure. Do you have to give up your LAYERS? No, but you have to acknowledge the actual place the legacy has within the structure. In fact, it may help to characterize the legacy. The SERVICES the legacy provides may in fact be confined to only a few LAYERS. To be able to say that the legacy system fits within particular RESPONSIBILITY LAYERS concisely describes a key aspect of its scope and role.
假设你打算采用 RESPONSIBILITY LAYER 模式，但你有一个遗留系统，它的组织结构与你想要采用的大型结构不一致。那么是否必须放弃 LAYERS 模式？不必，但是你必须确定遗留系统在新结构中的位置，如图 17-4 所示。实际上，RESPONSIBILITY LAYER 可能有助于刻画遗留系统的特征。遗留系统所提供的 SERVICE 可以被限定到几个层中。如果我们能够说出遗留系统与哪几个特定的 RESPONSIBILITY LAYER 相符，那么这就非常精确地描述了遗留系统的范围和角色的关键方面。
A structure that allows some components to span layers
If the legacy subsystem’s capabilities are being accessed through a FACADE, you may be able to design each SERVICE offered by the FACADE to fit within one layer.
如果遗留子系统的功能是通过一个 FACADE 来访问的，那么设计时，该 FACADE 所提供的每个 SERVICE 应该只在一个层中，不跨越多个层。
The interior of the Shipping Coordination application, being a legacy in this example, is presented as an undifferentiated mass. But a team on a project with a well-established large-scale structure spanning the CONTEXT MAP could choose, within their CONTEXT, to order their model by the same familiar LAYERS.
在这个示例中，Shipping Coordination 应用程序是一个遗留系统，它的内部机制是作为一个无差别的整体呈现出来的。但如果项目团队已经很好地建立了一种跨 CONTEXT MAP 的大型结构，那么团队可以选择在他们的 CONTEXT 中按照已经熟悉的层来组织模型，如图 17-5 所示。
The same structure applied within a CONTEXT and across the CONTEXT MAP as a whole
Of course, because each BOUNDED CONTEXT is its own name space, one structure could be used to organize the model within one CONTEXT, while another was used in a neighboring CONTEXT, and still another organized the CONTEXT MAP. However, going too far down that path can erode the value of the large-scale structure as a unifying set of concepts for the project.
当然，由于每个 BOUNDED CONTEXT 都是其自己的命名空间，因此在一个 CONTEXT 中可以使用一种结构来组织模型，而在相邻的 CONTEXT 中则可以使用另一种结构，然后再使用一种别的结构来组织 CONTEXT MAP。但是，使用过多的结构会损害大型结构作为项目统一概念集的价值。
The concepts of large-scale structure and distillation also complement each other. The large-scale structure can help explain the relationships within the CORE DOMAIN and between GENERIC SUBDOMAINS.
大型结构和精炼的概念也是互为补充的。大型结构可以帮助解释 CORE DOMAIN 内部的关系以及 GENERIC SUBDOMAIN 之间的关系，如图 17-6 所示。
MODULES of the CORE DOMAIN (in bold) and GENERIC SUBDOMAINS are clarified by the layers.
At the same time, the large-scale structure itself may be an important part of the CORE DOMAIN. For example, distinguishing the layering of potential, operations, policy, and decision support distills an insight that is fundamental to the business problem addressed by the software. This insight is especially useful if a project is carved up into many BOUNDED CONTEXTS, so that the model objects of the CORE DOMAIN don’t have meaning over much of the project.
同时，大型结构本身可能也是 CORE DOMAIN 的一个重要部分。例如，把潜能层、作业层、策略层和决策支持层区分开，能够提炼出对软件所要解决的业务问题的基本理解。当项目被划分为多个 BOUNDED CONTEXT 时，这种理解尤其有用，这样 CORE DOMAIN 的模型对象就不会具有过多的含义。
When you are tackling strategic design on a project, you need to start from a clear assessment of the current situation.
当对一个项目进行战略设计时，首先需要清晰地评估现状。
- Draw a CONTEXT MAP. Can you draw a consistent one, or are there ambiguous situations?
- Attend to the use of language on the project. Is there a UBIQUITOUS LANGUAGE? Is it rich enough to help development?
- Understand what is important. Is the CORE DOMAIN identified? Is there a DOMAIN VISION STATEMENT? Can you write one?
- Does the technology of the project work for or against a MODEL-DRIVEN DESIGN?
- Do the developers on the team have the necessary technical skills?
- Are the developers knowledgeable about the domain? Are they interested in the domain?
- 画出 CONTEXT MAP。你能画出一个一致的图吗？有没有一些模棱两可的情况？
- 注意项目上的语言使用。有没有 UBIQUITOUS LANGUAGE？这种语言是否足够丰富，以便帮助开发？
- 理解重点所在。CORE DOMAIN 被识别出来了吗？有没有 DOMAIN VISION STATEMENT？你能写一个吗？
- 项目所采用的技术是遵循 MODEL-DRIVEN DESIGN，还是与之相悖？
- 团队开发人员是否具备必要的技能？
- 开发人员是否了解领域知识？他们对领域是否感兴趣？
You won’t find perfect answers, of course. You know less about this project right now than you ever will in the future. But these questions give you a solid starting point. By the time you have specific initial answers to these questions, you’ll have started getting insight into what most urgently needs to be done. As time goes along, you can refine the answers—especially the CONTEXT MAP, DOMAIN VISION STATEMENT, and any other artifacts you’ve created—to reflect changed situations and new insights.
当然，我们不会发现完美的答案。我们现在对项目的了解永远不如将来的了解深入。但这些问题为我们提供了一个可靠的起点。当知道了这些问题的初步答案后，我们就会明白什么是最迫切需要解决的。随着时间的推进，我们可以得出更精炼的答案，特别是 CONTEXT MAP、DOMAIN VISION STATEMENT，以及其他创建出来的工件，这些答案都反映出了变化的情况和新的理解。
Traditionally, architecture is handed down, created before application development begins, by a team that has more power in the organization than the application development team. But it doesn’t have to be that way. That way doesn’t usually work very well.
传统上，架构是在应用程序开发开始之前建立的，并且在这种组织中，负责建立架构的团队比应用开发团队拥有更大的权力。但我们并不一定得遵循这种传统的方式，因为它并不总是十分有效。
Strategic design, by definition, must apply across the project. There are many ways to organize a project, and I don’t want to be too prescriptive. However, for any decision-making process to be effective, some fundamentals are required.
战略设计必须明确地应用于整个项目。项目有很多组织方式，这一点我并不想做过多的说明。但是，要想使决策制定过程更有效，需要注意一些基本问题。
First, let’s take a quick look at two styles that I’ve seen provide some value in practice (thus ignoring the old “wisdom-from-on-high” style).
首先，我们简单介绍一下我曾见过的两种在实践中具有一定价值的风格（摒弃了传统的“由高层制定决策”的做法）。
A self-disciplined team made up of very good communicators can operate without central authority and follow EVOLVING ORDER to arrive at a shared set of principles, so that order grows organically, not by fiat.
一个非常善于沟通、懂得自律的团队在没有核心领导的情况下照样能够很好地工作，他们能够遵循 EVOLVING ORDER 来达成一组共同遵守的原则，这样就能够有机地形成一种秩序，而不用靠命令来约束。
This is the typical model for an Extreme Programming team. In theory, the structure may emerge completely spontaneously from the insight of any programming pair. More often, having an individual or a subset of the team with some oversight responsibility for large-scale structure helps keep the structure unified. This approach works well particularly if such an informal leader is a hands-on developer—an arbiter and communicator, and not the sole source of ideas. On the Extreme Programming teams I have seen, such strategic design leadership seems to have emerged spontaneously, often in the person of the coach. Whoever this natural leader is, he or she is still a member of the development team. It follows that the development team must have at least a few people of the caliber to make design decisions that are going to affect the whole project.
这是极限编程团队的典型模式。从理论上讲，任何一对儿编程人员都可以根据自己的理解来完全自发地创建一种结构。通常，让团队中的一个人（或几个人）来承担大型结构的一些监管职责有利于保持结构统一。如果这位承担监管职责的非正式的领导人也是一位负责具体工作的开发人员（仲裁者和协调员），而不是决策的唯一制定者，那么这种方法将特别有效。在我见过的极限编程团队中，这样的策略设计领导者可能会自动出现，而且通常在教练中产生。不管这个自动出现的领导人是谁，他仍然是开发团队的成员之一。由此可见，开发团队必须至少有几位具有这样才干的人，由他们来制定一些运用到整个项目中的设计决策。
When a large-scale structure spans multiple teams, closely affiliated teams may begin to collaborate informally. In such a situation, each application team still makes the discoveries that lead to the idea for a large-scale structure, but then particular options are discussed by the informal committee, made up of representatives of the various teams. After assessing the impact of the design, participants may decide to adopt it, modify it, or leave it on the table. The teams attempt to move together in this loose affiliation. This arrangement can work when there are relatively few teams, when they are all committed to coordinating with each other, when their design capabilities are comparable, and when their structural needs are similar enough to be met by a single large-scale structure.
当多个团队使用同一种大型结构时，密切相关的团队可以开始非正式的协作。在这种情况下，对这种大型结构，每个应用程序团队仍会产生各自的想法，而其中一些具体选择会由一个非正式的委员会来讨论，这个委员会由各个团队的代表组成。在评估了这些选择对设计的影响之后，委员会决定是采用它、修改它，还是放弃它。团队在这种松散的合作关系下一起前进。这种安排要想发挥作用，需要保证：团队数目相对较少，各个团队之间能够一致地保持彼此协调，他们的设计能力大致相同，而且他们的结构需求基本一致，可以通过同一种大型结构来满足。
When a strategy will be shared among several teams, some centralization of decision making does seem attractive. The failed model of the ivory tower architect is not the only possibility. An architecture team can act as a peer with various application teams, helping to coordinate and harmonize their large-scale structures as well as BOUNDED CONTEXT boundaries and other cross-team technical issues. To be useful in this, they must have a mind set that emphasizes application development.
当几个团队共用同一种策略时，确实需要集中制定一些决策。架构师如果脱离实际开发工作，就可能会设计出失败的模型，但这是完全可以避免的。架构团队可以把自己放在与应用开发团队平等的位置上，帮助他们协调大型结构、BOUNDED CONTEXT 边界和其他一些跨团队的技术问题。为了在这个过程中发挥作用，架构团队必须把思考的重点放在应用程序的开发上。
On an organization chart, this team may look just like the traditional architecture team, but it is actually different in every activity. Team members are true collaborators with development, discovering patterns along with the developers, experimenting with various teams to reach distillations, and getting their hands dirty.
在组织结构图中，这样的团队看起来与传统的架构团队没什么分别，但实际上二者在每一项活动中都存在不同。架构团队的成员是真正的开发协作者，他们与开发人员一起发现模式，与各个团队一起通过反复实验进行精炼，并亲自动手参与开发工作。
I have seen this scenario a couple of times, when a project ends up with a lead architect who does most of the things on the following list.
这种场景我曾经见到过几次，项目最终会由一位架构师来领导，下面列出的大部分工作都会由他来完成。
Decisions must reach the entire team
决策必须传达到整个团队
Obviously, if everyone doesn’t know the strategy and follow it, it is irrelevant. This requirement leads people to organize around centralized architecture teams with official “authority”—so that the same rules will be applied everywhere. Ironically, ivory tower architects are often ignored or bypassed. Developers have no choice when the architects’ lack of feedback from hands-on attempts to apply their own rules to real applications results in impractical schemes.
显然，如果不能确保团队中的所有人都知道策略并去遵守它，那么策略也就失去了作用。这个要求引导人们以架构团队（具有正式的“权威”）为中心组织到一起，以便在整个项目中应用一致的规则。然而具有讽刺意味的是，那些脱离实际开发工作的架构师往往会被人们忽略或躲开。如果架构师没有实践经验，又试图把他们自己的规则强加于实际的应用程序，那么他们所设计出来的模式就会不切实际，这时开发人员除了忽略他们之外别无选择。
On a project with very good communication, a strategic design that emerges from the application team may actually reach everyone more effectively. The strategy will be relevant, and it will have the authority that attaches to intelligent community decisions.
在一个沟通良好的项目中，应用开发团队所产生的策略设计实际上会更有效地传播到每个人。这样策略将会实际发挥作用，而且具有权威性，因为它是通过集体智慧制定的决策。
Whatever the system, be less concerned with the authority bestowed by management than with the actual relationship the developers have with the strategy.
无论开发什么系统，都不要用管理层所授予的权力来强制地推行战略决策，而应该更多地关注开发人员与策略之间的实际关系。
The decision process must absorb feedback
决策过程必须收集反馈意见
Creating an organizing principle, large-scale structure, or distillation of such subtlety requires a really deep understanding of the needs of the project and the concepts of the domain. The only people who have that depth of knowledge are the members of the application development team. This explains why application architectures created by architecture teams are so seldom helpful, despite the undeniable talent of many of the architects.
无论是建立组织原则、大型结构还是那些微妙的精炼，都需要真正理解项目的需求和领域概念。那些唯一具有这方面深层次知识的人就是应用程序开发团队的成员。这解释了为什么架构团队所创建的应用架构很少对项目产生帮助，尽管我们必须承认很多架构师都非常有才能。
Unlike technical infrastructure and architectures, strategic design does not itself involve writing a lot of code, although it influences all development. What it does require is involvement with the application development teams. An experienced architect may be able to listen to ideas coming from various teams and facilitate the development of a generalized solution.
与技术基础设施和架构不同，战略设计虽然影响到所有的开发工作，但是它本身并不需要编写很多代码。战略设计真正需要的是应用开发团队的参与。经验丰富的架构师可以听取来自各个团队的想法，并促进总体解决方案的开发。
One technical architecture team I worked with actually circulated its own members through the various application development teams that were attempting to use its framework. This rotation pulled into the architecture team the hands-on experience of the challenges facing the developers, while it simultaneously transferred the knowledge of how to apply the subtleties of the framework. Strategic design has this same need of a tight feedback loop.
我曾经与一个技术架构团队合作过，这个团队把成员轮流派到使用其架构的各个应用开发团队中。这种流动性使架构团队亲身体验到了开发人员所面临的挑战，同时也把如何应用框架的知识传播给了开发人员。战略设计同样需要这种紧密的反馈循环。
The plan must allow for evolution
计划必须允许演变
Effective software development is a highly dynamic process. When the highest level of decisions is set in stone, the team has fewer options when it must respond to change. EVOLVING ORDER avoids this trap by emphasizing ongoing change to the large-scale structure in response to deepening insight.
有效的软件开发是一个高度动态的过程。如果最高层的决策已经固定下来，那么当团队需要对变更做出响应时，选择就会更少。遵循 EVOLVING ORDER 这一原则，可以避免出现这个问题，因为它强调的是根据理解的不断加深来调整大型结构。
When too many design decisions are preordained, the development team can be hobbled, without the flexibility to solve the problems they are charged with. So, while a harmonizing principle can be valuable, it must grow and change with the ongoing life of the development project, and it must not take too much power away from the application developers, whose job is hard enough as it is.
当很多设计决策过早地固定下来时，开发团队可能会束手束脚，失去解决问题的灵活性。因此，虽然那些为了协调项目而制定的原则可能很有价值，但原则必须能够随着项目开发生命周期的进行而完善和变化，而且不能过分限制应用程序开发人员的能力，因为开发工作本来就已经很难了。
With strong feedback, innovations emerge as obstacles are encountered in building applications and as unexpected opportunities are discovered.
有了积极的反馈之后，当构建应用程序的过程中遇到障碍或是出现了意想不到的机会时，创新就自然而然地涌现出来了。
Architecture teams must not siphon off all the best and brightest
架构团队不必把所有最好、最聪明的人员都吸收进来
Design at this level calls for sophistication that is probably in short supply. Managers tend to move the most technically talented developers into architecture teams and infrastructure teams, because they want to leverage the skills of these advanced designers. For their part, the developers are attracted to the opportunity to have a broader impact or to work on “more interesting” problems. And there is prestige attached to being a member of an elite team.
架构层次的设计确实需要技术精湛的人员，而这样的人员总是供不应求。项目经理往往会把那些最有技术天分的开发人员调到架构团队和基础设施团队中，因为他们想要充分利用这些高级设计人员的技能。在项目经理看来，开发人员都希望提高自己的影响力，或是攻克那些“更有趣”的问题。而且，加入精英团队本身也会赢得威望。
These forces often leave behind only the least technically sophisticated developers to actually build applications. But building good applications takes design skill; this is a setup for failure. Even if a strategy team creates a great strategic design, the application team won’t have the design sophistication to follow it.
这样往往会把那些技术能力较差的人留下来构建应用程序。但要想开发出优秀的应用程序，是需要设计技巧的，因此这样安排注定会造成项目失败。即使战略团队建立了一个很好的战略设计，应用程序开发团队也没有能力把它实现出来。
Conversely, such teams almost never include the developer who perhaps has weaker design skills but who has the most extensive experience in the domain. Strategic design is not a purely technical task; cutting themselves off from developers with deep domain knowledge hobbles the architects’ efforts further. And domain experts are needed too.
相反，架构团队几乎从来不会把那些缺乏设计技巧但精通领域知识的开发人员吸纳进来。战略设计并不是一项纯粹的技术任务，把那些精通深层次领域知识的开发人员排除在外只会使架构师的工作更难进行。而且同样也需要领域专家的参与。
It is essential to have strong designers on all application teams. It is essential to have domain knowledge on any team attempting strategic design. It may simply be necessary to hire more advanced designers. It may help to keep architecture teams part-time. I’m sure there are many ways that work, but any effective strategy team has to have as a partner an effective application team.
所有应用程序团队都应该有一些技术能力很强的设计人员，而且任何从事战略设计的团队也都必须具有领域知识，这两者都是非常重要的。聘用更多高级设计人员是很有必要的，而且使架构团队偶尔从事一下开发工作也会很有帮助。我相信有很多有用的方法，但任何有效的战略团队必须要与一个有效的应用程序团队通力合作。
Strategic design requires minimalism and humility
战略设计需要遵守简约和谦逊的原则
Distillation and minimalism are essential to any good design work, but minimalism is even more critical for strategic design. Even the slightest ill fit has a terrible potential for getting in the way. Separate architecture teams have to be especially careful because they have less feel for the obstacles they might be placing in front of application teams. At the same time, the architects’ enthusiasm for their primary responsibility makes them more likely to get carried away. I’ve seen this phenomenon many times, and I’ve even done it. One good idea leads to another, and we end up with an overbuilt architecture that is counterproductive.
任何设计工作都必须精炼而简约，而战略设计尤为需要简约。即使是一个非常小的设计失误也有可能会变成可怕的隐患。把架构团队单分出来时要格外慎重，因为他们将更少感知他们为应用程序开发团队所设置的障碍。同时，架构师对其主要职责的过度关注会使他们迷失方向。我就曾多次看到过这种情况，甚至我自己也犯过这种错误。有了一个好的想法后，又会引出另一个想法，想法太多最后就会得到一个过度设计的架构，这种体系结构反而起到了负面作用。
Instead, we have to discipline ourselves to produce organizing principles and core models that are pared down to contain nothing that does not significantly improve the clarity of the design. The truth is, almost everything gets in the way of something, so each element had better be worth it. Realizing that your best idea is likely to get in somebody’s way takes humility.
相反，我们必须严格地约束自己，从而使设计出来的组织原则和核心模型精简到只包含那些能够显著提高设计清晰度的内容。事实上，几乎任何事物都会对其他某个事物构成障碍，因此每个元素都必须是确实值得存在的。我们需要有一个谦逊的态度，才能认识到我们自己认为的最佳思路可能会妨碍其它人。
Objects are specialists; developers are generalists
对象的职责要专一，而开发人员应该是多面手
The essence of good object design is to give each object a clear and narrow responsibility and to reduce interdependence to an absolute minimum. Sometimes we try to make interactions on teams as tidy as they should be in our software. A good project has lots of people sticking their nose in other people’s business. Developers play with frameworks. Architects write application code. Everyone talks to everyone. It is efficiently chaotic. Make the objects into specialists; let the developers be generalists.
良好的对象设计的关键是为每个对象分配一个明确且专一的职责，并且把对象之间的互相依赖减至最小。人们有时会试图让团队中的交流像软件中的交互那样整齐。其实在一个优秀的项目中，会有很多人参与其他人的事情。开发人员有时也处理框架，而架构师有时也会编写应用程序代码。所有人员都可以互相交流。这看似混乱但却行之有效。因此，应该让对象职责专一，而让开发人员成为多面手。
Because I’ve made the distinction between strategic design and other kinds of design to help clarify the tasks involved, I must point out that having two kinds of design activity does not mean having two kinds of people. Creating a supple design based on a deep model is an advanced design activity, but the details are so important that it has to be done by someone working with the code. Strategic design emerges out of application design, yet it requires a big-picture view of activity, possibly spanning multiple teams. People love to find ways to chop up tasks so that design experts don’t have to know the business and domain experts don’t have to understand technology. There is a limit to how much an individual can learn, but overspecialization takes the steam out of domain-driven design.
把战略设计与其他设计区分开，是为了帮助澄清所涉及的工作，但必须指出：这两种设计活动并不意味着有两种人员。虽然基于深层模型创建柔性设计是一种高级设计活动，但细节问题也至关重要，因此战略设计工作必须由接触编码工作的人来完成。战略设计源自应用设计，然而战略设计需要一个总体的开发活动视图，这个视图可能跨越多个团队。人们总喜欢想出各种办法把工作分得很细，以使得设计专家不必了解业务，而领域专家也不用知道技术。确实，一个人能学的知识是有限的，但过于专业化也会削弱领域驱动设计的力量。
Technical frameworks can greatly accelerate application development, including the domain layer, by providing an infrastructure layer that frees the application from implementing basic services, and by helping to isolate the domain from other concerns. But there is a risk that an architecture can interfere with expressive implementations of the domain model and easy change. This can happen even when the framework designers had no intention of venturing into the domain or application layers.
技术框架提供了基础设施层，从而使应用程序不必自己去实现基础服务，而且技术框架还能帮助把领域与其他关注点隔离开，因此它能够极大地加速应用程序（包括领域层）的开发。但技术框架也是有风险的，那就是它会影响领域模型实现的表达能力，并妨碍领域模型的自由改变。甚至当框架设计人员并没有特意去干涉领域层或应用层的时候，情况同样如此。
The same biases that limit the downside of strategic design can help with technical architecture. Evolution, minimalism, and involvement with the application development team can lead to a continuously refined set of services and rules that genuinely help application development without getting in the way. Architectures that don’t follow this path will either stifle the creativity of application development or will find their architecture circumvented, leaving application development, for practical purposes, with no architecture at all.
用于克服战略设计缺点的原则同样适用于技术架构。遵守演变、简约等原则并且让应用程序开发团队参与进来，就能够得到一组持续精化的服务和规则，这些服务和规则能够真正有助于应用程序的开发，而不会妨碍开发。如果架构不按照这种方式来做，那么它们要么会抑制应用程序开发的创造力，要么会被人们绕过去，从而导致应用程序为了能够把开发进行下去而根本不使用架构。
There is one particular attitude that will surely ruin a framework.
有一种态度肯定会使框架流于失败。
Don’t write frameworks for dummies
不要编写“傻瓜式”的框架
Team divisions that assume some developers are not smart enough to design are likely to fail because they underestimate the difficulty of application development. If those people are not smart enough to design, they shouldn’t be assigned to develop software. If they are smart enough, then the attempts to coddle them will only put up barriers between them and the tools they need.
在划分团队时，如果认为一些开发人员不够聪明，无法胜任设计工作，而让他们去做开发工作，那么这种态度可能会导致失败，因为他们低估了应用程序开发的难度。如果这些人在设计方面不够聪明，就不应该让他们来开发软件。如果他们足够聪明，那么这种隔离只会造成障碍，使他们得不到所需的工具。
This attitude also poisons the relationship between teams. I’ve ended up on arrogant teams like this and found myself apologizing to developers in every conversation, embarrassed by my association. (I’ve never managed to change such a team, I’m afraid.)
这种态度还会损害团队之间的关系。我就曾经在这样傲慢自大的团队中感到疲惫不堪，于是我每次谈话都得向开发人员道歉，我自己也因为有这样自大的同事而感到难堪（我恐怕永远也无法改变这样的团队）。
Now, encapsulating irrelevant technical detail is completely different from the kind of prepackaging I’m disparaging. A framework can place powerful abstractions and tools in developers’ hands and free them from drudgery. It is hard to describe the difference in a generalized way, but you can tell the difference by asking the framework designers what they expect of the person who will be using the tool/framework/components. If the designers seem to have a high level of respect for the user of the framework, then they are probably on the right track.
注意，把无关的技术细节封装起来与我所反对的这种“傻瓜式”的预打包完全不同。框架可以为开发人员提供有力的抽象和工具，使他们不用去做那么多苦差事。有用的封装和“傻瓜式”的预打包之间的区别很难用一种通用的方式描述出来，但只要问问框架设计人员他们对将要使用工具/框架/组件的那些人有什么期望，就可以看出区别。如果设计人员对框架的用户非常尊重，那么他们的工作方向可能就是正确的。
A group of architects (the kind who design physical buildings), led by Christopher Alexander, were advocates of piecemeal growth in the realm of architecture and city planning. They explained very nicely why master plans fail.
由 Christopher Alexander 领导的一群建筑师（设计大楼的建筑师）在建筑和城市规划领域中提倡“聚少成多地成长”（piecemeal growth）。他们非常好地解释了总体规划失败的原因。
Without a planning process of some kind, there is not a chance in the world that the University of Oregon will ever come to possess an order anywhere near as deep and harmonious as the order that underlies the University of Cambridge.
如果没有某种规划过程，那么俄勒冈州大学的校园永远不会像剑桥大学校园那样庞大、和谐而井井有条。
The master plan has been the conventional way of approaching this difficulty. The master plan attempts to set down enough guidelines to provide for coherence in the environment as a whole—and still leave freedom for individual buildings and open spaces to adapt to local needs.
总体规划是解决这种难题的传统方法。它试图建立足够多的指导方针，来保持整体环境的一致性，同时仍然为每幢建筑保留自由度，并为适应局部需要预留下广阔的空间。
- . . . and all the various parts of this future university will form a coherent whole, because they were simply plugged into the slots of the design.
- . . . in practice master plans fail—because they create totalitarian order, not organic order. They are too rigid; they cannot easily adapt to the natural and unpredictable changes that inevitably arise in the life of a community. As these changes occur . . . the master plan becomes obsolete, and is no longer followed. And even to the extent that master plans are followed . . . they do not specify enough about connections between buildings, human scale, balanced function, etc. to help each local act of building and design become well-related to the environment as a whole.
- . . . The attempt to steer such a course is rather like filling in the colors in a child’s coloring book . . . . At best, the order which results from such a process is banal.
- . . . Thus, as a source of organic order, a master plan is both too precise, and not precise enough. The totality is too precise: the details are not precise enough.
- . . . the existence of a master plan alienates the users [because, by definition] the members of the community can have little impact on the future shape of their community because most of the important decisions have already been made.
—From The Oregon Experiment, pp. 16–28 (Alexander et al. 1975)
- ……将来这所大学的所有部分将构成一致的整体，因为它们只是被“插入”到总体设计的各个位置中。
- ……实际上总体规划会失败，因为它只是建立了一种极权主义的秩序，而不是一种有机的秩序。它们过于生硬，因此不容易根据自然变化和不可预料的社会生活变化来做出调整。当这些变化发生时……总体规划就过时了，而且不再被人们遵守。即使人们遵守总体规划……它们也没有足够详细地指定建筑物之间的联系，人口规模、功能均衡等这些用来帮助每幢建筑的局部行为和设计很好地符合整体环境的方面。
- ……试图驾驭这种总体规划过程非常类似于在小孩的填色本上填充颜色……这个过程最多也不过是得到一种极为平常的秩序。
- ……因此，通过总体规划是无法得到一种有机的秩序的，因为这个规划既过于精确，又不够细致。它在整体上过于精确了，而在细节上又不够细致。
- ……总体规划的存在疏远了用户[因为，从根本上讲]大部分重要决策已经确定下来了，因此社区成员对社区未来的建设几乎没有什么影响了。
——摘自 Oregon Experiment, pp.16-28[Alexander et al.1975]
Alexander and his colleagues advocated instead a set of principles for all community members to apply to every act of piecemeal growth, so that “organic order” emerges, well adapted to circumstances.
Alexander 和他的同事倡议由社区成员共同制定一组原则，并在“聚少成多地成长”的每次行动