一开始对SOA的担心之一，是组织必须对整个企业进行变革才能实现有意义的SOA推广。许多组织视之为非此即彼的命题。在许多情况下，这往往会导致失败，因为组织并没有尝试大规模的采用，那样会发生太多的变化，与此前的应用交付方式相比相差太大。

现在，组织意识到自己采用基于领域的方法可以实现更加成功的SOA部署。这允许组织以有意义的、成功的方式逐步推进SOA部署。

Thomas Erl，Arcitura Education Inc.的CEO，同时也是包括《SOA设计模式》在内的若干SOA相关书籍的作者。他说，SOA成功的关键在于选择一个相关的领域，该领域能以可管理的方式贯穿公司的各个孤立部分。在识别相关领域、做出决策以及实现最相关和最有价值领域方面，资深的企业架构师能扮演主要角色。

Erl解释说，“意识到基于领域我们能实现更加成功的SOA部署会导致在SOA实现方式上发生彻底变化。它允许SOA层层推进。允许我们识别在IT企业的什么部分能让我们实现平衡。”

建立特定领域的详细目录

对于企业来说，建立一个企业服务详细目录是很困难的。如果做得糟糕，会危及整个SOA行动的成功。领域详细目录的想法是指服务可归类进特定领域的详细目录，从而各自进行标准化、治理和管理。

Erl已经发现采用领域的主要原因跟业务服务之下的业务逻辑有关。每一个部门可能都有着不同的以业务文档体现的业务逻辑和数据模型，这些形成了划分边界和建立不同领域的基础。

为了让这些领域有意义，服务必须贯穿各个相互孤立的部分，Erl说。在企业层建立领域也很重要，这样它们才能由集中化的IT团队管理。每一个领域都可以随着组织向SOA转变而逐步采用。

领域可以基于地理、自治区、不同的计算环境、业务单元或运营单元划分。按业务线划分领域对于拥有不同产品目录的大型企业集团来说会比较有意义。另一方面，按照运营进行划分，对于需要在销售、客户服务、质量控制和物流等运营部门之间划分边界时显得比较有意义。

在基于领域来实现SOA时，形成的标准没有必要在整个企业范围内采用。每一个业务单元都可以利用业务部门常见的现有数据模型为特定业务流程建立服务，不同部门均可拥有和管理这样的服务。采用好的边界使每一个部门可以保持服务目录的同步，从而令涉及的业务模型对其他领域产生的影响最小化。

阶段设置

企业架构师需要在标准实施时扮演角色。这将改善特定SOA项目的成功采用，为更大范围的SOA采用铺平道路。Erl说，“如果SOA对于一个组织来说是个新事物的话，这种方法的风险很低，可以在开始更大范围推广前让IT员工接触到与SOA随之而来的所有的实践、技术、设计原则及模式。”

对于治理之类的事情来说这一点特别重要，因为那些事情需要IT团队确保所要建构的元素可用于直接需求之上的服务。他们交付的是具有特定特征的服务，这些服务会成为他们要衡量和检查的解决方案的一部分。他们需要能够交付预期可作出改变的服务。

在这些边界确定以后，企业架构师的最佳实践是与业务部门经理一道定义与特定领域相关的数据模型，命名规范及规则。好的标准规范可改善服务构成的能力，同时还能减少沟通不同领域的需要。

对于企业架构师来说，与不同项目团队协作也很重要，这样才能确保有重复功能的服务在组织不是独立地开发。

协调各部分

为不同的业务部门建立的服务之间也许会有不同，因为它们的标准化是各自进行的。每一个领域可能也要依赖不同的数据模型、技术或技术的不同版本。

如果建立企业级的标准不可行，那么就需要一些桥接机制来将贯穿领域边界的服务整合到一起。这些情况下，你需要考虑能协调数据模型转换、数据格式转换及协议桥接等不同服务的设计模式。

采用跨领域的功能层设计模式有助于为不同业务部门开发的服务提供一个公共基础设施。这一层处理领域之间的转换，从而克服差异性问题。企业用它来维护以技术为中心的服务，组织的多个部门都需要它。

不同部门可利用这些模式，但是要想管理这些服务，他们必须有不同的治理方法。这可以让这些服务得到跨领域的重用，从而使得每一个部门无需在自己的领域再建这些服务，而组织既可以采用基于领域的方法，永不会造成领域之间彻底相互隔绝。它还提高了跨领域的重用和标准化的可能性。在组织内重用这些服务还减少了开发时间。

提示问题

以下是寻求基于领域方法时需要考虑的一些问题：

• 每个企业部门都是谁来管理这些服务的？
• 地理边界会不会对企业范围内的部署造成问题？
• 组织的不同部门是由不同IT部门支持的吗？还是IT集中化管理的？
• 特定业务部门对于SOA所能提供的敏捷性之类的需求是不是更大？
• 不同的业务部门使用不相互兼容的数据模型吗？
• 不同部门的IT经理会不会放弃对项目开放方式的控制？

在企业内实施SOA在敏捷性和成本节省方面能为企业带来显著的长远利益。然而，如果组织一下子试图接管太多的东西，这些努力有可能就会失败。找出在技术上、IT支持及政治障碍方面更容易实施的更小一点的领域，从最容易的地方着手是个好主意。这些项目的早期成功将有助于为在组织内实施范围更广的SOA项目做好准备。