领域对象发展的极致就是代理

作者：Einar Landre
译者：徐培
校审：钱平、伍斌

---

从这到那，又回来了。——Bilbo Baggins

1. 介绍

本文解释什么是动态领域建模（dynamic domain modelling），为何需要它，以及使其成为领域驱动设计一等公民的价值。首先，我要感谢Eric对软件社区的开创性贡献，还要感谢他和我在下面两项工作中所进行的精彩讨论——参与挪威跨国能源公司Equinor（前身是Statoil公司）的石油贸易投资组合项目，并为OOPSLA技术大会撰写论文。与Eric讨论是一段很棒的经历。

《领域驱动设计》这本书出版已经有15年了。那时候，没有iPhone，没有Facebook，没有Netflix，亚马逊刚刚盈利两年。 Windows 2000还是微软的旗舰操作系统，Sun Microsystems还是一家领先的科技公司，Java已有9年历史，而关系数据库统治着企业的数据中心。

从那时起，云计算、大数据、移动应用、物联网、边缘计算、机器学习和人工智开始成为我们专业词汇的一部分。 诸如Swift、Scala和Go之类的新编程语言开始登上舞台，而Python之类的旧语言开始复活，并在数据科学中占主导地位。

显而易见，我们的行业经历了深刻的变化。这些变化，使得领域驱动设计变得更加重要，同时也要求领域驱动设计本身进行改变，以适应软件定义世界的需求。

2. 领域复杂性

领域复杂性

英国系统思想家Derek Hitchins认为，复杂性是多变性、连接性和无序性的函数。如果组件之间的差异越大，组件之间的连接更多，并且连接相互纠缠（而非有序），那么我们认为事物会越复杂。

复杂性的挑战，在于其中涉及了两种类型的连接，即能导致结构复杂性的稳定连接，和能导致动态复杂性的任意连接。

领域的结构复杂性常见于嵌套结构，例如下面事物中的组件层次架构——产品（飞机，船舶）、零售分类或项目计划。让这些对象变得复杂的因素，包括其内部状态模型、规则及对象之间的连通性和可变性的深度。

领域的动态复杂性，源于自治组件或自治对象之间的交互。这就是在动态系统中所见到的复杂性。对象内部可能具有高度的复杂性，而对象之间不断变化的交互作用和任意连接性，造就了动态复杂性。

来去匆匆的对象们，可能因对方行为或沟通的缺失而迷路，可能会相互协作、竞争、组建团队。一个对象所采取的行为，会直接影响其他对象的可选项。

领域驱动设计解决了结构复杂性的问题。其中的实体、值对象、聚合、存储库和服务等概念，是结构性构建块，有助于创建有序性，减少耦合性，从而简化限界上下文内部及之间可变性的管理。

而动态复杂性的问题则完全没有解决。Vernon在他的书中引入了领域事件的概念，这是一个良好的开端。但我们需要的不仅仅是事件，还需要在企业消息软件上下文中管理事件的方式。

3. 代理

现实世界由动态系统所组成。领域的动态复杂性源于异步、并发、竞争和协作的过程。

创建面向对象编程的目的，原本是为了通过仿真技术研究和分析一个系统中各个过程，当时的仿真编程语言Simula提供了必要的支持。但不知为何，面向对象的软件社区失去了对动态系统的兴趣，却将关注点转向了编程语言。而动态系统的研究，则留给了控制论（cybernetics）和人工智能（AI）社区。

值得一提的是，控制论和人工智两者之间亲如手足。它们都是在1940年代后期的研讨会上构思出来的。两者的差异点在于，控制论学者倾向于使用微积分和矩阵代数作为工具，来解决适合这些工具的问题，比如由固定的连续变量集所描述的系统。而AI社群则没有这些限制，而是选择了逻辑推断与计算工具。这使他们能够处理语言、视觉和规划等问题。

在AI社区中，理性行动的思想催生了理性代理（agent，源自拉丁语agere，意为做事），也称智能代理，例如可工作的计算机程序。当然，所有程序都能工作，但代理应该做得更多——包括能自主运行、持续运行、适应环境、做出改变、创造和追求目标。理性代理是能为实现最佳结果而采取行动的代理（此定义出自Russel和Norvig）。

智能代理是一种能通过观察环境解决问题，并针对该环境执行操作的程序。在这期间，代理可以扮演角色，与其他代理（包括人类）协作并互动。

智能软件（Software wise）是智能代理的对象，能控制自身的执行线程，自主运作，并能做有趣的事情。但问题是，几乎无人将代理视为领域对象，我认为这必须改变。

为了说明代理也是领域对象，下面提供一段能概括代理的结构Java代码：

结构Java代码

智能代理是人工智能的基石。其种类繁多，小到机器人，大到宇宙飞船。智能代理是理解其自主性（与代理的学习能力密切相关）的关键。

智能代理的难题，是代理推理方法（或称作代理功能）的实现，即将给定的感知或目标与可能的最佳动作进行映射。代理功能可以非常简单，也可能非常复杂，我尝试使用能力栈来说明这些功能：

• 使用诸如智能代理软件模型BDI和认知架构Soar之类的工具，实现基于推理的行为
• 使用数字滤波器、数学控制系统，模糊逻辑和神经网络，用以发现连续的行为
• 使用有限状态机，构建状态驱动的行为
• 使用无记忆能力的函数（例如读取测量值），表示的简单行为

要实现最复杂的代理功能，意味着要将诸如Soar和BDI这样的认知架构，与工具箱中的所有其他的可用工具结合起来使用。Soar由John Laired和Allen Newell于1983年创建，现由密歇根大学Laird的研究小组所维护。BDI（全称Beliefs-Desires-Intentions 信念-期望-意图）是由Michael Bratman于1991年在他的人类实用推理理论中创建。目前正在进行的有关Soar和BDI的研究，都受到美国国防部门对智能代理自主能力的需求的推动。

Soar和BDI这两种领域模型，都是对人类大脑如何推理并将感知转化为行动所进行的建模。这两种架构都获得开源和商业实现的支持，例如JACK、BDI4Jade、Gorite和SOAR。

4. 动态领域建模

在教授面向对象编程时，已故教授Kristen Nygaard使用了咖啡馆里的人物作为他的系统隐喻。在观察咖啡馆里的人物时，我们会发现做有趣事情的对象，如服务员、顾客、门卫和收银员，以及定义和描述事物的对象，如菜单、食物、账单和餐桌等。

咖啡店

行为建模面向那些做有趣事情的对象。这种建模从任务环境开始，并引出更详细的事件和任务模型。任务环境定义了上下文，并且定义了有哪些代理（如服务员），代理的绩效指标（如良好的用餐体验），代理的操作环境（如餐厅）以及代理的执行器（如言语、手和脚）和传感器（如眼睛和耳朵）。

事件和任务模型会使用一系列问题，以此将高层次的目标分解为更详细的任务：要执行的任务是什么？什么事件触发了某项任务？任务的预期成效是什么？发送了什么消息？以及谁是接收者？谁执行了这项任务？在执行任务时会创建哪些事件？

在开发事件和任务模型时，需要考虑两个重要因素：首先，哪些任务将同时执行？并且它们是否会争用相同的资源？如果是，那么就会面临竞态条件和可能的死锁，所以需要并发编程技能。其次，如果任务的执行时间有限，即必须在给定的时间范围内完成任务，那么我们需要有实时系统的技能。

为了支持动态系统的建模，我们需要在领域驱动设计工具箱中添加4个概念：

• 任务，即代理要执行的工作。
• 代理，即感知其环境并执行任务的对象。
• 代理功能，即代理如何将其感知映射到其所要执行的任务的能力。
• 事件，即发生了的事情，且因此触发了要执行的任务。

只要把这4个概念打造为领域驱动设计的一等公民，那么我们就有把握去构建更丰富和更强大的领域模型，从而构建物联网、工业4.0、人工智能和一个可用软件无处不在的世界。

对于那些想要更进一步钻研的人来说，Douglas、Russel和Norvig以及Jarvis等人的著作都是很好的读物（详见下文）。Hitchins的书则是为特别感兴趣的人而准备的。我期望所有人都已经读了Eric或Vernon的书。

5. 感言

有人可能会问，代理和微服务有什么不同？我的答案是粒度。代理是对象，它们最终由所选语言中的构造函数来定义。

如果领域问题最需要使用认知架构来解决，那么建议去找一个成熟的框架，而不用自己构建。

为什么现在要提“领域对象的极致就是代理”？

• 物联网以及软件定义世界的趋势，改变了商业软件的规则。后台进程必须能够响应边缘事件，还必须能够向边缘进程和设备实时发送新指令。
  自动化工作始于捕获任务。
• 希望你现在可以理解这一点——代理是许多领域的一等公民，是领域对象发展的极致。

---

参考文献

• Douglas, Doing hard time, Developing real-time systems with UML, Objects, Frameworks and Patterns.

• Evans, Domain-Driven Design, Tackling the complexity at the heart of software.

• Hitchins, Advanced systems, thinking, engineering and management.

• Jarvis et al, Multiagent Systems and Applications: Volume 2: Development Using the GORITE

• BDI Framework.

• Russel, Norvig, Artificial intelligence, A modern approach, third edition.

• Vernon, Implementing Domain Driven Design.