[译文]Domain Driven Design Reference（七）—— 大型战略设计结构
本书是Eric Evans对他自己写的《领域驱动设计-软件核心复杂性应对之道》的一本字典式的参考书，可用于快速查找《领域驱动设计》中的诸多概念及其简明解释。
上周末电脑硬盘文件莫名丢失，狼狈了大半周才缓过来 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句不是很顺，但也没办法了】，这样就能在不违反模型开发的前提下，大大澄清系统。因为一个不合适的结构比没有更糟糕，所以最好不要选择全面性，而是寻找一个最小的集合来解决已经出现的问题。少即是多。
接下来是在一些项目中出现的四种特定模式的大规模结构，它们是这种模式的代表。
系统隐喻
隐喻思维在软件开发中非常普遍，特别是对于模型。但是，“隐喻”的极限编程实践，使用隐喻为整个系统的发展带来秩序已经成为一种特殊的方式。
软件设计往往是非常抽象和难以理解的。开发人员和用户都需要切实的方法来理解系统，并共享整个系统的视图。
因此：
当一个与系统的具体类比出现时，它抓住了团队成员的想象力，并且似乎将思维导向有用的方向时，把它作为一个大规模结构。围绕这个隐喻组织设计，并将其吸收到通用语言中。系统隐喻既能促进关于系统的交流，又能引导系统的发展。这增加了系统不同部分的一致性，甚至可能跨越不同的限界上下文。
职责层
在面向对象的设计中，每个对象都被分配了一系列的相关职责。责任驱动设计也适用于较大规模。
当每个单独的对象都有手工制定的职责时，没有指导原则，不统一，也没有能力一起处理大范围的领域。为了实现一个大型模型的一致性，对这些责任的分配施加一些结构是有用的。
因此：
查看模型中的概念依赖关系，以及领域不同部分的变化率和变化源。如果你确定了领域中的自然层次，就把它们作为宽泛的抽象职责。这些职责应该讲述一个关于您的系统的高级目标和设计的故事。重构模型，使每个领域对象、聚合和模块的职责完全符合一个层的职责。
知识层次
一组描述另一组对象应该如何表现的对象。
在一个应用程序中，实体之间的角色和关系在不同的情况下有所不同，复杂性可能会爆炸。既不是完全通用的模型，也不是用户需要的高度定制的模型。对象最终引用其他类型来涵盖各种情况，或者在不同情况下以不同方式使用的属性。具有相同数据和行为的类可能只是为了适应不同的程序集规则而组装。
因此：
创建一组可用于描述和约束基本模型的结构和行为的独特对象。将这些关注点分为两个“层次”，一个非常具体，另一个反映用户或超级用户能够自定义的规则和知识。
（见Fowler，M.1997。分析模式：可重复使用的对象模型，Addison-Wesley。）
可插拔组件框架
机会出现在一个非常成熟的模型中，并且是深入和精炼的。一个可插拔组件框架通常只有在几个应用程序已经在同一个领域中实现之后才开始发挥作用。
当各种应用程序必须互操作时，所有的应用程序都基于相同的抽象，但是独立地设计，在多个有界的上下文之间的转换会限制集成。对于不紧密协作的团队来说，共享内核是不可行的。复制和碎片化增加了开发和安装成本，互操作性变得非常困难。
因此：
提炼接口和交互的抽象核心，并创建一个允许这些接口的各种实现自由替换的框架。同样，允许任何应用程序使用这些组件，只要它严格地通过抽象核心的接口进行操作即可。
作者：Zachary
出处：https://zacharyfan.com/archives/311.html
▶关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描右侧的二维码~。
定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。
如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。
如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。
