DDD 领域驱动设计落地实践系列：初识 DDD( 三 ) _DDD

这个定义看上去有种不明觉厉的感觉，我们还是以大家最熟悉的电商场景来进行说明下。电商系统中以用户购物为例子，用户浏览商品之后，选择了对应的商品进行下单，在生成订单之后，积分服务队用户的购物积分进行增加，库存服务将对应商品的库存进行扣减，优惠券服务向用户发放新的优惠券，物流服务将接管后续的成品物流信息。在这个典型的用户下单购物场景下，用户服务负责提供用户信息以及用户的统一管理，那么关于用户的一切操作都是在用户域完成的，包括用户的名称、密码等信息的维护以及注册、登录等动作的实施。那么我们可以认为这里的用户服务就是用户领域，它是这个电商系统中的一个子域。

文章插图

对于领域模型来说，我们可能会任务它是一个大而全的能够概括整个业务系统的全能型的模型，实际上不是的，定义这样一个模型也是十分困难的事情。在实际落地实施过程中，我们更加愿意在各个子域中实现领域模型的建立，而这个领域模型就在这个限界上下文中完成实现。
所以说领域模型就是针对某个特定业务领域的软件模型，如电商业务领域中的订单、积分、库存、配送等都是电商业务领域的子域。领域模型通过对象模型描述真实的业务场景，精确表达业务语义，它是实际业务场景中的流通货币。
在整个业务团队中，领域专家、设计人员、开发人员需要对领域模型有统一的认识，大家都认可。在不同的子域中就会有不同的领域模型，那么我们怎么来区分不同的领域模型呢，实际上就是通过限界上下文来进行区分。
3、限界上下文
这个概念怎么说呢，既好理解，又不好理解。限界上下文是一个显式的概念性边界，我们的领域模型都是此边界中，我们都知道领域模型是使用同一语言描述的软件模型，每个领域模型都有对应的属性和动作，这些属性和动作需要在一个特定的上下文环境中才有特定的意义。打个比方，笔记本在文具领域那么它就是一个纸质的记录工具，同样是笔记本这三个字但是在 3C 领域中，它指的又是我们常用的笔记本电脑。同样的名称但是在不同的边界上下文中代表的含义是完全不同的。因此实际上，限界上下文为团队创建了一个建模边界，团队成员在边界内部实现解决方案。

文章插图

通过上面的例子我们可以把限界上下文理解为一种农场中的圈子，有的圈子是养猪的、有的圈子是用来种植蔬菜的，如果没有限界上下文那么猪就有可能把蔬菜吃过了，但是有了围栏（限界上下文）之后，我们可以在不同圈子中进行喂养或者灌溉，互不影响从而使得农场可以很好的运转起来。农场的圈子和围栏我们可以实实在在看的到，那么到了软件系统中领域边界就是一种抽象视图。
如下所示，在电商这个业务领域中，包含了订单、物发票以及库存等子域以及对应的限界上下文。

文章插图

总结
本文主要围绕什么是 DDD，DDD 给我们的架构设计带来怎样的价值进行了说明，并分析了软件架构设计存在的复杂性，因此我们需要 DDD 这种复杂架构分析方法协助我们完成领域建模以及微服务划分。通过上文我们大致了解了 DDD 是干什么用的以及一些重要的概念，那么下篇文章我们将继续阐述 DDD 实践的两大设计过程，敬请期待哈。

【DDD 领域驱动设计落地实践系列：初识 DDD】