【注】本文译自：https://www.thoughtworks.com/…
  这篇文章是对于软件设计的抉择。特地是大型零碎，这些零碎可能会以服务端点的模式分为多个可部署的对象。我不会特地议论服务端点设计，然而我想探讨创立多个服务利用的构思阶段。

  当咱们面对简单的问题时，咱们通常试图了解简单的单个局部。通过合成问题，咱们将其变成为更易于了解和治理的局部。
  正如在许多产品 / 项目管理周期中所形容的，对于现实生活中的问题，这通常是由本能驱动的。咱们不会应用公式来理解去一个须要签证的国家须要做什么。咱们晓得咱们须要签证能力旅行，咱们缓缓把握须要的文件文件，须要填写哪些表格以及如何填写这些表格。当咱们执行其中一个步骤时，咱们不会将流程的所有细节都牢记在心，而只是要做手头的工作。这与要实现的工作的大小无关。潜在的实在规范是对于工夫或进度、咱们的执行力、咱们的认知能力及其与工作相熟水平的关系，甚至可能是执行这些工作的物理地位（领事馆与 Photoshop 等）。
  在软件开发畛域并没有什么不同。多年来，瀑布式的配方已被利用到软件开发过程中，最终，次要是基于启发式和基于教训的评估技术（打算扑克 <Planning Poker>、T – 恤尺寸 <T-shirt size>）和麻利过程。在现实生活中，咱们试着不去详述整个过程，而是通过观察咱们的最新体现来尝试和了解整个旅程。
  同样实用于咱们针对问题建模的软件。咱们开始将它们合成为不同的利用的是方便管理单个利用，以更少的依赖关系更快地开发和部署，最初带来更多的技术抉择自在。咱们意识到，咱们无奈制订出适宜所有人的残缺流程。咱们着眼于各个局部，并意识到咱们在设计模式或技术方面的个体教训，并尝试利用其中最好的抉择。
  了解和解决复杂性的一个乏味的软件设计技术是 畛域驱动设计 （DDD）。畛域驱动设计提倡基于与咱们的用例相干的业务事实进行建模。因为 DDD 办法当初曾经过期，而且宣传程度正在降落，咱们许多人都遗记了 DDD 办法的确有助于了解手头的问题，并朝着对解决方案的广泛了解来设计软件。在构建利用 DDD 会以域和子域的模式探讨的问题。它将问题的独立步骤 / 畛域形容为边界上下文，强调应用一种通用语言来探讨这些，并增加了许多技术概念，如 实体、值对象和聚合根 规定以反对实现。有时，这些技术规定被视为是施行 DDD 的硬阻碍，但最终，人们往往会遗记重要的局部是依据业务问题组织代码工件，并应用与（1）雷同的通用语言。

设计为服务利用的边界上下文

  我想议论的架构格调与微服务十分类似。它是对于将单体利用拆散为多个独立的服务利用，或者从一开始就在边界上下文（DDD 概念）的帮忙下独自开发它们。
  有许多资源都强调了微服务叙述中更细粒度的服务的长处。越来越多的文章、博客和其余内容是对于陷阱和在向细粒度服务过渡之前或过渡期间应该领有的安全网的。我将尽量不反复微服务或其余反对元素的益处，这些是迁徙到这样的体系结构中所须要。我不想强调后果服务的“小型”性质，而是想强调如何通过应用领域驱动的设计概念来更好地拆散这些服务。
  让咱们应用一个实在的示例来实现咱们的想法 - 借记卡 / 信用卡获取域。这个畛域能够（可怜的是，很多时候都是这样）作为一组单体利用来实现。咱们领有多个利用的惟一起因是因为不同的利用中的存在严格的技术限度（例如心愿执行批处理）。

  我所看到的大多数胜利的架构都意识到，通过数据库进行集成是一种蹩脚的实际，因为它使技术利用和业务职责之间的界线变得含糊，使业务逻辑透露到数据库中, 并通过增加更多的应用服务器来阻止程度扩大。因而，以单体利用的的服务集成的模式倒退到更好的架构。

  当初，利用之间的界线更加清晰了。然而，您能够看到，依然存在暗藏的数据库交互，这一次是在各个利用外部产生的。我称它们为暗藏的，因为通常一开始它们通常很难被留神到。随着工夫的流逝，代码的纠缠将使原先拆散的业务流程人为地关联起来，并在业务开发中引入更多的摩擦，因为这种共置托管须要联结部署独自的性能，这可能会减慢速度。
  如果您幸运地有一个畛域模型来领导的话，则领域建模可帮忙您辨认和拆散简单的实现。如果您还没有现有利用的域模型（在大多数状况下通常是这样），则无需遍历代码以理解不同的职责，而是构建域模型并将性能映射到手边的利用可能是一个更好的办法。这既能节省时间，又能防止被细节吞没的危险。此外，如果业务与开发团队之间存在差距（这可能是域模型最后不存在的次要起因），那么探讨域模型并映射到现有利用的性能将有助于放大这一差距。

  咱们设计演进的下一步是将域边界拆散反映到咱们的架构以及边界上下文中。一个域具备多个边界上下文意味着在同一域中能够有多个服务利用运行。有了适当的域模型，潜在的分离点就更可见了，这使咱们能够从潜在的更细粒度的利用中受害（诸如独自发行和版本控制的益处，具备更多功能驱动的纯服务端点的后劲等，其中大多数曾经在 微服务 文章中进行了探讨）。只管许多微服务探讨都围绕技术不可知论和开发标准（防止 / 毁坏整体），但对于咱们大多数人所从事的利用而言，十分有价值的一项是畛域和设计方面。一旦过渡到微服务架构（借助域模型），DDD 和更细粒度的服务便能够协同工作、相互支持。

  这还将为团队提供肯定水平的独立性，更欠缺的服务性能以及更拆散的交互，如许多微服务文章所述.
  同样，从咱们的示例信用卡付款获取域中能够看出，这并不是咱们的服务能够做到的最细粒度的拆散。相同，这是在咱们的畛域常识所领导下最有意义的拆散。重点不是规模，而是业务能力。我置信这是“正确的 SOA”，正如许多圈子所说的那样。