一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第2天。

1.货运公司业务概述

领域驱动设计一书中多次提到作者参与过的一个货运公司软件项目。但是个人觉得作者没有把这个项目的业务做个简要的描述，这给很多不了解货运业务的读者造成了一定的理解难度。

举个简单的例子，假如香港一家公司A 卖了一批货（Cargo）给位于美国达拉斯的一个公司B。A 致电委托这家货运公司将货物运输到B 指定的位于达拉斯火车站的一个货仓。货运公司会根据A 的要求规格（Specification）给这批货安排航线（Itinerary），下图是一个航线示例，航线包含两段航段（Leg，书中也有用transport-运输，或者voyage-航程，表达的意思都是一段运输航程，可以认为是同义词）：一段是从香港港口到美国加州长滩（Long Beach）港口的货轮，航次为ABC（类似于火车车次，飞机航班号）；一段是长滩港口到达拉斯的火车车次为XYZ。不管是船运还是火车运输，对于每一段航程都需要装货（Load）和卸货（Unload）。

货物进入一个国家需要做清关（customs clearance）。清关也叫结关或通关，是指货物到达目的港口，为货物按照该国海关规定办理各种进口货物的手续，经过海关核验后放行的过程。

对于货运公司来说A 和 B 都是其客户（Customer），A是托运人，委托货运公司帮其运输货物。B是收货人（Receiver)。这个业务中还有一个付款人（Payer）来支付运输费用。付款人通常是托运人，也就是A。也有收货人承担运输费的。甚至可能是另外一个第三方，比如A 委托其母公司C 来支付运输费。付款人也是运输公司的客户（Customer）。

2.什么是领域（Domain）

领域就是软件要解决的问题所涉及的业务知识（Knowledge）。在货运公司这个案例中，我们要解决的问题是用计算机软件来实现货物运输预定、安排航线及跟踪货物。它的领域就是货运公司在货物运输预定、安排航线及跟踪货物业务中实际的业务操作和逻辑，也就是业务知识。本文的第一部分给出了这个领域知识的概要描述。

为了解决领域问题，计算机专家（需求分析师/产品经理）需要去观察业务操作，与领域专家沟通，以获得领域知识。

3.什么是模型（Model）

模型是对要解决的问题的相关的领域的抽象表达。模型不是UML图。UML图或者其他模型图只是模型的一种表达方式，目的是帮助我们表达和解释模型。领域模型是会不断优化的。刚开始的时候，我们对于领域的理解可能不够全面和深刻，这个时候抽象提炼出来的模型能够解决手上的问题，但是可能不够优雅。随着我们对领域知识理解逐步加深，再经过仔细的思考探寻，我们的模型会迭代进步，变得更加优雅而深刻。

书中用了一个非常简洁而又深刻的模型图表达了货物运输的领域模型，如下图：

4.Ubiquitous Language

Ubiquitous Language，就是统一的语言，也就是领域模型所表达的领域知识。当讨论问题领域相关的问题的时候，我们软件工程师与领域专家，软件工程师之间都应该使用这个统一语言来进行日常的沟通。因为在问题领域中，Ubiquitous Language是建模过程中整理抽象出来的，领域专家和软件工程师都能准确理解的语言。在传递问题领域相关信息方面信息含量是最高的，也是最准确的，沟通效率最高。如果不用Ubiquitous Language，每个人都用自己习惯的语言，势必在沟通的过程中，需要不断的对称和翻译。这样不仅效率低下，甚至造成错误的理解。

Ubiquitous Language 通常包含领域类和主要操作的名称；领域知识中的概念、术语；领域模型中的常用的模式。