本书是埃里克·埃文斯对他自己写的《领域驱动设计——软件核心复杂性应对之道》的一本字典式的参考书,可用于快速查找《领域驱动设计》中的诸多概念及其简明解释。
,上周末电脑硬盘文件莫名丢失，狼狈了大半周才缓过来 T_T 。《Domain Driven Design Reference》的原版pdf也丢了，好在这篇文章提前翻好了，只是这次没法再次做校对了，大致读了一遍还算通顺，大家讲究看吧~
其它本系列其它文章地址：
[译文]Domain Driven Design Reference（一）—— 前言
[译文]Domain Driven Design Reference（二）—— 让模型起作用
[译文]Domain Driven Design Reference（三）—— 模型驱动设计的构建模块
[译文]Domain Driven Design Reference（四）—— 柔性设计
[译文]Domain Driven Design Reference（五）—— 为战略设计的上下文映射
[译文]Domain Driven Design Reference（六）—— 提炼战略设计
[译文]Domain Driven Design Reference（七）—— 大型战略设计结构
在一个大的系统中，没有任何能够让元素按照其在整个设计模式中的角色来解释它们，好比是开发人员无法看到树木的森林。我们需要能够理解个体在整体中的角色，而不需要深入研究整体的细节。
“大规模结构”是一种语言，可让您广泛地讨论和理解系统。一组高级概念或规则，或两者都为整个系统建立了设计模式。这个组织原则可以指导设计和帮助理解。它有助于协调独立的工作，因为有一个共同的概念:各个部分的角色如何塑造整体。
因此：
设计一种规则或角色和关系的模式，它将跨越整个系统，并且在不详细了解该部分责任的情况下，允许对整个系统中的每个部分进行一些理解。
演化有序
无设计的生产系统是没有人能理解整体的，而且它们很难维护。但是，架构可以用预先设计的假设来约束一个项目，并且从应用程序特定部分的开发人员/设计人员那里获得大量权力。很快，开发人员就会降低应用程序以适应结构，或者他们会破坏这个结构，并且根本就没有任何结构，这就导致了不协调开发的问题。
因此：
让这个概念性的大型结构与应用程序一起演进，可能会在过程中变成一种完全不同的结构类型。不要过度限制详细的设计和模型决策必须要有详细的知识。
当一个结构可以被发现的时候，就应该采用大规模结构【这2句不是很顺，但也没办法了】，这样就能在不违反模型开发的前提下，大大澄清系统。因为一个不合适的结构比没有更糟糕，所以最好不要选择全面性，而是寻找一个最小的集合来解决已经出现的问题。少即是多。
接下来是在一些项目中出现的四种特定模式的大规模结构，它们是这种模式的代表。
系统隐喻
隐喻思维在软件开发中非常普遍，特别是对于模型。但是，“隐喻”的极限编程实践，使用隐喻为整个系统的发展带来秩序已经成为一种特殊的方式。
软件设计往往是非常抽象和难以理解的。开发人员和用户都需要切实的方法来理解系统，并共享整个系统的视图。
因此：
当一个与系统的具体类比出现时，它抓住了团队成员的想象力，并且似乎将思维导向有用的方向时，把它作为一个大规模结构。围绕这个隐喻组织设计，并将其吸收到通用语言中。系统隐喻既能促进关于系统的交流，又能引导系统的发展。这增加了系统不同部分的一致性，甚至可能跨越不同的限界上下文。
职责层
在面向对象的设计中，每个对象都被分配了一系列的相关职责。责任驱动设计也适用于较大规模。
当每个单独的对象都有手工制定的职责时，没有指导原则，不统一，也没有能力一起处理大范围的领域。为了实现一个大型模型的一致性，对这些责任的分配施加一些结构是有用的。
因此：
查看模型中的概念依赖关系，以及领域不同部分的变化率和变化源。如果你确定了领域中的自然层次，就把它们作为宽泛的抽象职责。这些职责应该讲述一个关于您的系统的高级目标和设计的故事。重构模型，使每个领域对象、聚合和模块的职责完全符合一个层的职责。
[译文]领域驱动设计参考(七)——大型战略设计结构
