当你设计数据架构时，会很容易得出不同的数据库或者数据库表。该数据库表中包含相同或相近的数据。所有这些记录在册的数据可以帮助更好的维护数据，解决质量问题。这样建立起来的数据规范成为了最受欢迎的数据建模实施。从本质上来说，数据规范化的目标就是尽可能降低数据的赘余度。这样就迫使每一个使用特定数据类型的应用必须通过一个位置访问服务规范。因此，通过降低数据的冗余度，数据规范可以促进时间重用。

　　可重用性也是服务定向的主要目标之一。服务定向的其中一项原则就是确保服务的质量得以实现。服务规范是众多支持服务可重用性模式中其中的一种模式，但是，服务规范的目标远不止支持服务可重用性。同数据规范一样，服务规范模式意在降低冗余度，减少不必要的消耗，以避免治理负担（维护相似服务逻辑体，并使相似服务逻辑体保持同步，同时复制服务逻辑）。

　　要想实现这个目标，服务规范首先要在服务之间划定界限，这样服务就不会重叠。和数据规范不同，服务规范并没有受限于数据。服务规范主要考虑的是基本服务界限的规范化。因此，你经常会感觉自己在服务建模时期正在实施这种模式，这个时期也是服务最初概念化的时期。

　　要想理解服务规范实施，最重要的一方面就是要弄清楚开展规范化任务的范围。正如我们在这一系列文章中所提到的，通过网域清单，可以在一个IT企业里建立许多由独立标准服务和管理服务所组成的集合。这些服务清单（有时被称为“服务大陆”）准许你实现服务定向目标。

　　服务清单蓝图通常都是在分析和建模期间确定下来的，一个特定蓝图的界限决定了服务规范的实施范围。这意味着，只要是在域服务清单范围内发生（而不是某个特定的服务清单）你就可以覆盖服务界限和冗余的服务逻辑。

　　这个由服务规范确立的原则融入了服务建模流程以及全局服务交付方法。避免功能覆盖是我们需要考虑的首要问题，也是专用流程步骤的基础。（尤其是迭代实施的建模流程）。当许多不同的小组平行工作，为相同的服务清单建立服务时，需要跟踪并协调这个问题。

　　尽管我们采取了多种措施，还是无法避免所有的功能重叠。服务蓝图以及具有相同功能的服务就有可能丢失某些东西。或者，硬约束限制了这种模式的完全应用。例如，不同的服务需要封装那些自身无法规范化的。在这种情况下，嵌入式逻辑或者确立的逻辑不可避免的会导致一定程度的冗余度。这时就出现了性能问题。你可能会遇到一种情况，就是完全规范化的服务会使运行的等待时间延长，解决这个 问题的唯一方法就是给服务设计一些非规范化方法。

　　在现实世界中，你可以这样解释这个模式“在一个服务清单中，没有两个服务界限可以重叠，如果二者发生了重叠，必须要有一个足够的理由！”，这也是服务规范化的总体目标，为支持服务定向目标建立一个坚实的基础。