要回答这个问题，需要三步走：为什么要建模；怎么建模才合理；“领域”模型具体指什么。
客户在专卖店买了个手机，留下了自己的名字和电话，店员做了记录。客人来时，只要店员能在记录里查到客人名字和电话的订单，就说明客人曾经买过手机。
什么人需要查看订单呢？店员 A 需要查看，店员 B 也需要查看。客人来咨询的时候，应该能随时调取。老板也需要查看，用来汇总销售情况。大家都要看，格式就必须统一，要不然有的只记了电话，有的只记了名字，有的什么都没记，就乱套了。
大家商量之后决定：订单必须包括客户名字、电话和购买的商品。那么就有“订单 = 名字 + 电话 + 商品信息”。这是店员和老板的心智模型（mental model）。
要用一个数字系统来支持订单的管理，必须形成对应的数据模型（data model），称之为数据建模（data modeling），中文简称建模。电脑采用数字化的精确储存，所以数据的格式必须提前明确，比如名字是 2-4 个中文字符，电话是 11 位数字等等。
建模本质上是一种抽象。抽象就是归类，其目的是减轻认知的负担，避免重复的思考和工作，提升人的计算能力。所以，“通用”是建模的第一步，接下来我们还需要“复用”建好的模型。
假设手机卖出之后，客户需要维修服务。 客户来到店里，询问店员，店员查询确认了订单，然后把客人引到门店旁边的维修中心。维修中心的工程师拿到订单，发现手机已经过了保修期，所以他写了一个维修单，把客户的名字、电话、手机信息、维修费用写到上面。客户交了费，拿到修好的手机，走了。
这引出一个问题。维修中心需要的客户信息，其实在店员那边有，没有必要自己再抄一遍，否则很容易出错，还会遇到信息同步的问题。那么，我们就需要再做一次建模，把客户的名字和电话从订单模型中拿出来，单独做一个客户模型。订单和维修单都复用这个客户模型。
这样，我们就得到了如下三个模型。
这里，维修单模型里面似乎包含了一个完整的订单（客户 + 商品信息），为什么不直接复用订单呢？也许是因为维修部门也负责别的地方购买的商品。另外，客户的名字和电话更新之后，是不是要直接修改已经完成的订单和维修单呢？值得商榷，已经完成的信息不应该有意料之外的变化。还有，如果客户是一个单独的模型，那么背后的团队会是怎么样呢？需要仔细考虑。
当数据模型可以完全覆盖业务需要，建模也就初步完成了。
那么，为什么要建模？第一，要把心智模型提取出来，显性化，让不同的人对业务的理解达成一致；第二，要归类复用，避免重复的工作，让人可以关注更高层面的事务。
如前面所示，即便是建立简单的模型，我们也需要诸多考虑。把这些需要考虑的点体系化，就引出了下一个问题：怎么建模才合理？