领域驱动设计之大型结构

        如果有很多MODULE。在这种情况下，开发人员要想查找某个功能，应该到哪个MODULE中去查呢?如果有了一个新类，应该把它放在哪里?这些小软件包的实际意义是什么?它们又是如何协同工作的呢?而且以后还要创建更多的MODULE。

      层并不是MODULE，也不是任何其他的代码工件。它们是一种全局性的规则集，用于约束整个设计中的任何MODULE或对象(甚至包括与其他系统的接口)的边界和关系。

     无论项目的规模如何，人们总需要有各自的分工，来负责系统的不同部分。如果没有任何协调机制或规则，那么相同问题的各种不同风格和截然不同的解决方案就会混杂在一起，使人们很难理解各个部分是如何组织在一起的，也不可能看到整个系统的统一视图。从设计的一个部分学到的东西并不适用于这个设计的其他部分，因此项目最后的结果是开发人员成为各自MODULE的专家，一旦脱离了他们自己的小圈子就无法互相帮助。在这种情况下，CONTINUOUS INTEGRATION 根本无法实现，而BOUNDED CONTEXT也使项目变得支离破碎。

      在一个大的系统中，如果因为缺少一种全局性的原则而使人们无法根据元素在模式(这些模式被应用于整个设计)中的角色来解释这些元素，那么开发人员就会陷入“只见树木，不见森林” 的境地。

    我们需要理解各个部分在整体中的角色，而不必去深究细节。
    “大型结构”是一种语言，人们可以用它来从大局上讨论和理解系统。它用一组高级概念或规则(或两者兼有)来为整个系统的设计建立一种模式。这种组织原则既能指导设计，又能帮助理解设计。另外，它还能够协调不同人员的工作，因为它提供了共享的整体视图，让人们知道各个部分在整体中的角色。

    设计一种应用于整个系统的规则(或角色和关系)模式，使人们可以通过它在一定程度上了解各个部分在整体中所处的位置(即使是在不知道各个部分的详细职责的情况下)。

      大部分大型结构都无法用UML来表示，而且也不需要这样做。这些大型结构是用来勾画和解释模型及设计的，但在设计中并不出现，它们只是用来表达设计的另外一种方式。