你上次从ATM机withdrew（取款）是什么时候?或者deposited（存钱）进你的bank account（银行账户）是什么时候？或者使用互联网银行来检查你的月工资是否被credited（记入）你的checking account（支票账户）?我在这里使用的英文，是让你们知道，这些是术语，是与银行的业务息息相关的~我们称之为个人银行的domain(领域).我们这里所看到的单词domain，它意味着对这块业务感兴趣的领域。当您正在开发一个自动化银行业务的系统时，您正在为个人银行业务建模。你设计的抽象，你实现的行为，以及你建立的UI交互都反映了个人银行的业务，它们构成了领域的model(模型)。

更正式地说，领域模型是 问题领域 各实体之间关系的蓝图，并勾勒出其他重要的细节，如以下:

• 属于领域的对象:例如没在银行领域中，你所拥有的诸如banks(银行)，accounts（账户）和transaction（交易）等。

• 这些对象在相互作用中表现出来的行为：例如在银行系统中，你从账户中debit（借款），你向客户端issue a statement（发表声明）。这些是在您的领域对象之间发生的典型交互。

• 领域的语言:当你对个人银行的领域进行建模时，诸如debit（借贷）、 credit（信用）、portfolio（投资组合）等术语，或者诸如“从账户1到账户2转账100美元”之类的术语，都是非常泛泛的，并形成了领域的词汇表。

• 模型运行的上下文:这包括与问题领域相关的一组设想和约束，并且自动适用于您开发的软件模型。比如只能为一个活着的人或者实体开一个新的银行账户-----这可以是为个人银行业务定义域模型上下文的设想之一。

与其他任何建模实践一样，实现域模型最具挑战性的方面是管理它的复杂性。其中的一些复杂性是问题的固有之所在，你无法回避它们。这些被称为系统的essential（必要）复杂性。例如，当您从您的银行申请个人贷款时，根据您的配置文件确定贷款金额额度有一个固定的复杂性，而这个复杂性是由领域的核心业务规则决定的。这是在解决方案模型中无法避免的必要复杂性。但是，解决方案本身引入了一些复杂性，比如当您实现了一个新的银行解决方案，它以额外批处理的形式引入了对操作的额外负载。这些被称为模型的incidental （附带）复杂性。

有效的模型实现的一个重要方面是减少附带的复杂性。通常情况下，您可以通过采用帮助您更好地管理复杂性的技术来减少模型的附带复杂性。比如，如果您的技术能够更好地模块化您的模型，那么您的最终实现就不是一个单一的、难以管理的软件。它被分解为多个小的组件，每个组件都在其自身的上下文中运行。图1.2描述了这样一个系统----为了简洁，我已经展示了两个组件。但您可以理解:使用模块化系统，每个组件在功能上都是自包含的，并且仅通过显式定义的契约与其他组件交互。有了这种布置，您就可以比单片系统更好地管理复杂性了。

ps:翻译下Figure1.2上面的几行英文：

上图是领域模型及其外部上下文的概览，并使用来自个人银行领域的术语。每个较小的模块都有自己的一组假设和业务规则，这些模块比大型单片系统更容易管理。但是，您需要至少保持它们之间的通信，并使用明确定义的协议。

本书解释了如何采用函数式编程的原则，并将它们与响应性设计相结合，从而实现了更易于创建、维护和使用的领域模型的实现。