八、把一切放到一起看看

在客户端，我们只需要让 pjax 劫持容器内的所有链接，使其发送一个 pjax 请求并插入适当的内容。 最终的结果是，页面的行为与带有链接的普通 HTML 页面类似，但页面不会在单击时完全刷新。 它将重新加载适当的块并更新窗口位置。

当构建需要大量服务器的应用时，这种方法非常有用，并且仍然能够维护一个流动的类似应用的界面，而不需要大量的构建开销，这涉及到完整的客户端呈现。 再一次,我们可以看到一个很大的区别,使前端更瘦客户端,因此这也许不是一个域驱动的主要候选方法,但与后端建立密切合作使用这种方法,因为它现在是真相的单一来源的应用逻辑。

使用 Javascript 服务器端

Javascript 作为一种语言，即使是，虽然它是为浏览器而开发的，但它并不仅限于在浏览器上下文中执行。 浏览器自然就包含了在页面上下文中执行 Javascript 的环境。 当我们想要在浏览器之外运行 Javascript 时，总是可以通过 Javascript 引擎直接执行它。 有多种不同的引擎可用，如 Mozilla 的Spidermonkey或谷歌的V8。 仅仅让 Javascript 可用显然是不够的，因此我们需要访问文件、套接字和许多其他东西，以便能够高效地处理服务器端代码。

Node.js 接管了这个部分，将谷歌 V8 引擎与标准 POSIX 函数绑定在一起，以访问系统级部分。 这绝不是第一个，还有来自 Mozilla 的Rhino，捆绑了 Java 生态系统和 Java，允许访问 Javascript 标准库之外的所有部分:

同样的事情在 Node.js 中看起来有点不同，更像我们期望的 Javascript:

有了交互的基础知识，我们就可以构建复杂的服务器端应用，并在有意义的地方利用服务器端开发的特性，就像我们在整本书中所做的那样。

提示

在即将发布的 ECMAScript 6 标准中，将引入一个新的模块语法，以增加客户端和服务器端的 Javascript 应用的模块化。 ECMAScript 6 几乎完成了，但在编写时它还不是随处可用。 是一个很好的源代码，用于即将进行的更改，并显式地用于 ECMAScript 6 模块，http://www.2ality.com/2014/09/es6-modules-final.html。

受控环境的优点

本书大部分内容依赖于 Node.js 作为执行环境的原因是，它提供了一组我们可以依赖的固定特性。 另一方面，浏览器一直是非常灵活和多变的。 在开发业务应用时，这是一个很大的优势。 作为开发人员，我们当然总是想要利用最新和最好的技术，在有意义的地方依赖这些技术是很有意义的，但我们也需要意识到稳定的平台在什么地方是最大的优势。

如果我们想为应用的业务逻辑建模，我们几乎不依赖任何新技术。 我们需要一个稳定的环境，在那里我们可以执行我们已经拥有的和将继续存在的东西。 当然，Javascript 的优势在于我们可以在客户端和服务器端执行，这意味着如果我们以后决定将某些逻辑滚到客户端，我们可以这样做，并且仍然可以在需要时退回到服务器端执行规则进行验证。

先进的模块化

在过去，Javascript 一直被称为浏览器语言，在很长一段时间里，加载脚本超出了语言本身的范围，而是由环境中的 HTML 部分通过脚本标记来处理的。

更高级的客户端应用的兴起和服务器端 Javascript 的兴起改变了这种语言。 这将在下一个版本中包含一个模块标准。 现在，有多种加载其他资源的方法，使用其中一种方法是一个好主意，但这很可能并不重要。 这里重要的一点是，加载外部模块可以让我们更好地将代码分割成逻辑单元，而不是像许多客户端 Javascript 程序那样需要 1000 多行文件。 在服务器端，这是一个已解决的问题，客户端也不远了。

有了这些不同类型的 Javascript 程序和挑战，我们就可以考虑在设计业务应用时我们的目标是什么，以及我们如何看到领域驱动设计在开发过程中扮演的角色。

每个业务应用在整个开发过程中都面临着不同类型的问题。 领域驱动设计的目标是隔离应用的复杂性，通过提供一种语言以及一组用于域内对象交互的规则，使其易于更改和维护。

正如我们在整本书中所看到的，领域驱动的设计都是关于业务逻辑建模的，因此领域专家可以访问它来进行判断和评估。 这是应用的重要部分，如果操作正确，可以在整个开发周期中节省很多麻烦。 当通过域驱动设计来驱动应用时，我们需要识别核心域及其子域。 取决于我们的领域是什么，用于建模的纯业务复杂性并不是唯一的复杂性。

对于业务规则来说，并非每个应用都很复杂，也不是每个应用都适合用我们在整个过程中看到的面向对象方法建模。 有不同性质的复杂性,经常接近困难的计算机科学思考为核心的问题领域,以及与每一领域都有其特定的说话方式和模型这些部分非常明显,我们应该用这个当我们遇到它。

提示

使计算机科学成为另一个商业领域是一种抽象的方法，我们在处理计算机科学问题时遇到的复杂性。 通常情况下，试图将这些问题暴露给业务领域本身是没有用的，而且会导致更多的混乱。 我们可以把计算机科学相关的主题作为我们互动的核心来解决非常具体的问题，如果我们想要孤立它，就可以这样发展它。

算法复杂度

|   | 在数学和计算机科学中，算法(i/ˈælɡərɪðəm/ AL-gə-ri-dhəm)是一套要执行的自包含的分步操作集。 |   |
|   | ——维基百科 |

在其核心，我们所做的所有事情都可以被描述为算法。 他们可能非常短，非常独特，但他们是一系列的步骤。 例如，我们在业务应用中遇到的算法是启动囚犯运输所需的一系列步骤。 我们遇到的算法是业务规则，最好作为域本身的一部分进行建模，因为它们直接涉及域对象。 然而，我们可以从数学或计算机科学中重用其他算法，这些算法更抽象，因此不适合业务领域。

当我们谈论算法复杂性时，我们通常指的是众所周知的算法，如树搜索或算法数据结构，如列表或跳过列表。 这些抽象的想法并不适合我们所建模的领域，而是在外部。 当我们在某个领域遇到一个问题，并且已知的算法很好地解决了这个问题时，我们应该利用这个事实，而不是用这些知识使这个领域变得混乱，而是保持它的独立性。

有些应用必定具有很高的算法复杂性，而且它们很可能不是领域驱动设计的主要候选者。 这方面的一个例子可能是搜索，大量的知识驻留在数据结构中，这使得搜索更加高效，因此可以在更大范围内使用。 重要的一点是，在这些领域中，业务专家就是开发人员，我们应该以一种开发人员能够进行最佳交流的方式来对待这个领域。 最基本思想保持一样,我们可能想要培养沟通通过常见的术语,但是在这种情况下,普通的开发商具体条款,和表达的最好方式是在代码中,因此,方法是编写代码,并尝试一下。

逻辑复杂性

与算法问题密切相关的另一个领域是逻辑问题。 取决于的领域，这些可以经常出现，并具有不同程度的复杂性。 此类问题的一个很好的例子是任何类型的配置器，例如，一个允许您订购汽车的应用涉及到额外组件可能冲突的问题。 取决于有多少不同的额外内容和冲突，问题可能很快就会失控。

在逻辑编程中，我们陈述事实，让引擎为我们推导可能的解决方案:

在前面的示例中，配置器由规则引擎支持，规则引擎允许配置器确定配置中的潜在冲突并将冲突报告给用户。 为了做到这一点，我们创建了一个事实或约束列表:

这样，当我们想要订购汽车时，规则引擎可以检查约束是否得到满足。

解决应用中的逻辑问题类似于算法问题，最适合为此目的构建的独立系统，公开特定于领域的逻辑语言，以逻辑术语清楚地表达问题，然后将其包装在领域中。

商业规则

当我们开发业务软件时，我们经常面临的复杂性是由我们开发软件的客户定义的业务规则。 这些规则的复杂性往往不是源于规则本身的高度复杂性，而是因为规则不是一成不变的，行为可以改变。 更重要的是，它需要快速更改以保持软件与业务相关。

实现业务规则意味着跟踪业务需要做什么，而这往往是基于业务领域专家头脑中的事实。 领域建模的重要部分是提取这些知识，并在整个业务中验证其有效性。 这是实域模型努力发挥作用的领域。

当我们能够与最了解该领域的人讨论该领域时，我们可以快速验证，如果我们与这个人使用共同的语言，他或她可以快速向我们解释未来的新规则。 通常，复杂的数据结构和算法不是构建的中心部分，比如应用，这些部分可以通过外部提供系统进行优化，领域的理解和灵活的建模是领域模型的力量所在。

在这本书中，我们专注于构建一个商业应用，从本质上确保我们不会超过或未预订我们的地牢，更具体地说，管理由于地牢的限制而需要移动的囚犯的转移。 作为开发人员，我们不得不严重依赖领域专家指导我们进行开发，因为我们还没有必要的业务领域知识。 在这种情况下，语言的建立非常有用，因为它允许我们以一种精确的方式谈论问题是什么，以及我们如何处理新的规则，从那时起。

在前面，我们已经看到并不是所有的域都适合这种策略，即使域也可能包含由辅助系统最好处理的部分。 特别是当开始一个新项目时，我们不能确定是否需要在一个重域层上进行投资。

银行应用

域指定好,有一个固定的规则集,并在很大程度上是处理应该是一个质数候选人被成熟的软件服务,为什么没有很多会计软件,为什么银行大量投资于他们的开发团队吗?

许多人从领域驱动的角度探讨会计问题，这些问题出现在类似的领域。 第一个是规则集，尽管这些规则似乎从外部定义得很好，但它们包含许多需要覆盖的边缘情况，并且需要正确覆盖，因为从本质上讲，大量资金正在系统中流动。 这些规则大多为一组专家所熟知，他们的工作就是在市场发生变化时进行必要的调整。 这给我们带来了第二个问题，许多非常微妙的更改需要表示，并在整个系统中保持一致。

所以,即使表面看来,关系数据库涵盖了很多情况下在一个银行应用,更改所需的敏捷性和内在需要很多沟通与银行专家使银行适合应用领域驱动设计后, 如果他们真的想开始新的发展。

提示

银行业是最好留给专家的领域之一。 如果不需要构建自己的会计系统，最好购买一个架子，因为领域复杂性和出错概率非常高。

旅游应用

在整个本书中，我们一直在关注与领域驱动设计、旅行和相关预订管理的另一个主要候选领域相关的领域。 比较地下城和酒店可能有点奇怪，但从软件的角度来看，两者的管理是相似的。 我们正在努力管理超额和过少预订，同时优化收入。

从表面上看，预订酒店是一个简单而明确的领域，但在深入挖掘时，往往会有许多调整和复杂的规则。 例如，在适当地查看数据库条目时，完全避免超额预订是很容易的，但这与最大化酒店收入的目标相违背。 需要一定数量的超额预订，以补偿最终退出的客人。

这不是管理预订的唯一复杂部分，业务的一个重要部分是根据季节和当前的市场情况进行调整。 预订酒店,而贸易展是在城里可以更昂贵的比普通的一天,尤其是如果不订了整个贸易展期间因为这将意味着一个房间可能保持空的,尽管它可能是轻松预订时可用于整个时间间隔。 另一方面，合作伙伴折扣可以让某些人在这些展览期间预订更便宜，我们希望确保这些人在预订其他客人时可以获得一定数量的房间。 所有预订都有多个需要管理的时间表，如折扣窗口、退款窗口等等。

近年来，领域驱动的设计使得旅行变得更加有趣，因为它的表现方式也有了很大的发展。 虽然之前这些系统被优化为可以通过电话或少数预订代理工作，但它们开始通过网络向公众开放。 这种暴露导致请求显著增加，也增加了所需的支持。 甚至在最近，这些系统不再直接操作，而是需要通过 api 进行访问，以便集成到搜索引擎中。

所有这些都使旅行变得复杂，远不止从数据库中存储和加载操作; 特别是，由于许多系统与一般公共访问相结合的集成给已开发系统的增长和扩展能力带来了巨大的负担，不仅在性能上，而且更重要的是在复杂性上。

域的先决条件

我们所关注的所有领域都涉及业务领域中不同形式的复杂性，这些复杂性可以使用领域驱动的设计方法得到很好的服务。 在前几节中，我们已经看到了非常适合这种方法的两个领域。 他们有什么共同之处?

正如之前所见，这都是关于我们需要处理的不同形式的复杂性。 在业务规则集中快速移动的领域需要更多地关注其建模，因为规则需要随着发展而调整。 更重要的是，不断发展的规则意味着开发人员不能完全理解规则，因此业务专家需要大量参与。 这意味着我们在领域驱动设计中构建的语言很快就会得到回报。 因此，领域驱动设计的一个重要部分是，它与开发人员的访问和理解领域的能力有关。 我们希望能够快速地将业务专家整合到流程中，以避免误解。 归根结底，业务专家才是推动领域发展的人。 作为开发人员，我们提供的软件可以让企业在其所做的事情上更成功。 作为我们领域驱动设计方法的一部分，我们确定了现在对业务真正重要的是什么，以及如何使其更有效和更不容易出错。

现在从另一个角度来处理这个问题，并且仍然考虑访问，这意味着从其他系统访问系统需要变得简单。 目前，许多领域都是如此，新设备一直都很流行，业务总体上朝着企业对企业环境中更高层次的集成迈进。 领域驱动的设计如何在其中发挥作用? 关键还是访问。 我们希望能够提供多个可从外部访问的接口，这些接口具有相同的底层逻辑。 在领域驱动设计中，我们都在构建一个强大的服务层，然后可以通过不同的接口将这一层公开给不同的系统，而不需要重复逻辑，这必然会导致部分和逻辑的分歧。

正如这本书的名字所暗示的那样,它已经深受 Eric Evans 的思想提出了在他的书《领域驱动设计:解决复杂的软件、addison - wesley,我建议这是一个后续。 通过提供不同的示例，并从经典 Java 后端方法的角度，他对通用方法进行了更详细的介绍。

另一本书,不应缺少任何后续软件设计,当然,的企业应用架构模式,马丁,addison - wesley,这是每天使用的大多数模式在面向对象的开发和进入更详细的一般模式。 本书更多地侧重于 Java 方面，但正如我们在本书中所看到的，以面向对象的方式使用 Javascript 是非常可能的，并且在许多建模场景中都会推荐使用它。

随着用 Javascript 编写的应用变得越来越复杂，对更强大的应用设计的需求也随之增加。 浏览器应用正在增长，对它们的业务依赖也在增长。 因此，曾经是后端开发的领域开始在前端开发中变得重要。 很长一段时间以来，人们一直在改进后端应用建模的灵活性，这样它们就可以随着业务的发展而增长，现在浏览器应用也需要这样做。 我们可以从这些年来开发的方法中学习到很多东西，尽管有些方法不能直接移植到 Javascript 中，甚至可能不需要，但总体思想移植得很好。 我希望我能在整本书中阐述这些观点。

另一方面，随着 Node.js 作为应用开发平台的兴起和采用，Javascript 也进入了后端，在 Rails 后端系统上需要解决 Java 或 Ruby 的相同挑战，现在需要为 Javascript/Node.js 解决。 保持 Javascript 的本质是很重要的，就像 Node.js 一样，目标通常是让系统更简单，更容易在更小的块中管理。 这反过来意味着 Node.js 后端采用了比传统企业 Java 系统更轻的建模方法。 这对开发人员来说是一种授权，因为全面的大规模架构讨论转向了自底向上构建的更实际的方法。 这并不意味着体系结构不重要，但是随着前端和后端系统复杂性的分离，复杂性可以用更轻松的方法更好地管理。