第六章：战略设计之大型架构
在没有任何总体原则的大型系统中，允许元素根据其在跨越整个设计的模式中的角色进行解释，开发人员只见树木不见森林，我们需要能够在不深入了解整体细节的情况下理解整个部分的作用。
“大型架构”是一种允许您广泛讨论和理解系统的语言。一组高级概念或规则或两者都为整个系统建立了一种设计模式。这种组织原则可以指导设计以及帮助理解。它有助于协调独立工作，因为有一个大局观的共同概念：各个部分的角色如何塑造整体。
因此：
设计一个规则或角色和关系模式，这些规则或角色和关系将跨越整个系统，并允许对整个系统的每个部分进行理解 - 即使没有对部件责任的详细了解。
不断演进的顺序
所有人都是自由设计生产系统，没有人能够理解整体，并且他们很难维护。但是，架构可以通过前期设计假设来紧缩项目，并且从应用程序的特定部分的开发人员/设计人员那里获得太多的权力。很快，开发人员将使应用程序笨拙以适应架构，或者他们将颠覆它并且根本没有架构，重新带回了不协调的开发问题。
因此：
让这个概念性的大型架构随着应用程序而演进，可能会在此过程中转变为完全不同类型的架构。不要过度约束在详细知识、详细设计和模型决策上。
当可以找到一个能够极大地澄清系统而不会对模型开发施加不自然约束的结构时，应该应用大型架构了。因为不适合的架构比没有架构更糟糕，所以最好不要为了全面性而进行某个时刻的立即设计，而是找到解决已经出现的问题的最小集合，少即是多。
接下来是在一些项目中出现的一组四种特殊的大型架构模式。
系统隐喻
隐喻思维（类比，比如时间就是金钱，将时间比喻成金钱）在软件开发中很普遍，尤其是模型。但是，“隐喻”的极限编程实践已经成为一种使用隐喻为整个系统的发展带来秩序的特定方式。
软件设计往往非常抽象，难以掌握，开发人员和用户都需要切实的方法来理解系统并分享整个系统的视图。
因此：
当系统的具体隐喻出现时，需要发挥团队成员的想象力(看到时间你能想到金钱吗？)，并且似乎引导思考朝着有用的方向发展，将其作为一个大型架构来实现。围绕这个比喻组织设计并将其吸收到无处不在的语言中。系统隐喻应该促进系统的沟通并指导系统的开发。这增加了系统不同部分的一致性，甚至可能跨越不同的有界环境。但是因为所有隐喻都是不精确的，所以不断重新审视过度扩张或不合适的隐喻，如果它妨碍了它就准备放弃它。
责任层
在面向对象的设计中，为各个对象分配了一组相关的相关职责。责任驱动设计也适用于更大规模。
当每个单独的对象具有手工制作的职责时，没有指导，没有统一性，也没有能力一起处理域的大块。为了使大型模型保持一致，在分配这些责任时强加一些结构是有用的。
因此：
查看模型中的概念依赖关系以及域的不同部分的变化率和变化源。如果您在域中识别自然层次，则将它们视为广泛的抽象职责。这些责任应该讲述系统的高级目的和设计。重构模型，使每个域对象，聚合和模块的职责完全符合一个层的责任。
（banq注：业务策略层、业规则层、业务操作层、业务监控层）
知识水平
描述另一组对象应如何表现的一组对象。
在实体之间的角色和关系在不同情况下变化的应用中，复杂性可能会爆炸。完全通用的型号和高度定制的型号都不能满足用户的需求。对象最终会引用其他类型以涵盖各种情况，或者使用在不同情况下以不同方式使用的属性。具有相同数据和行为的类可以相乘以适应不同的程序集规则。
因此：
创建一组不同的对象，可用于描述和约束基本模型的结构和行为。将这些问题分为两个“级别”，一个非常具体，另一个反映用户或超级用户能够自定义的规则和知识。
（见Fowler，M。1997. Analysis Patterns：Reusable Object Models，Addison - Wesley。）
可插拔组件框架
机会出现在一个非常成熟的模型中，这个模型是深度和蒸馏的。可插拔组件框架通常仅在一些应用程序已在同一域中实现后才起作用。
当各种应用程序必须互操作时，所有应用程序都基于相同的抽象但独立设计，多个有界上下文之间的转换限制了集成。共享内核对于不能紧密协作的团队来说是不可行的。复制和碎片化会增加开发和安装的成本，并且互操作性变得非常困难。
因此：
提取接口和交互的抽象核心，并创建一个框架，允许自由替换这些接口的各种实现。同样，允许任何应用程序使用这些组件，只要它严格地通过抽象核心的接口操作即可。(banq注：业务框架，比如GOSS的产品 服务框架，保险行业的当事人 资产和产品框架）